Date: Fri, 7 Apr 95 12:32:07 MDT From: terry@cs.weber.edu (Terry Lambert) To: babkin@hq.icb.chel.su (Serge A. Babkin) Cc: freebsd-hackers@FreeBSD.org Subject: Re: large filesystems/multiple disks [RAID] Message-ID: <9504071832.AA20804@cs.weber.edu> In-Reply-To: <199504071627.LAA00501@hq.icb.chel.su> from "Serge A. Babkin" at Apr 7, 95 11:27:29 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > Large databases don't allow predictive read-ahead because they > > typically can't be modelled using a model that assumes locality > > of reference. > > Oops. I throught that database manager can accept multiple requests > from clients in parallel and issue multiple parallel requests to > the disk subsystem. Is this wrong ? I wrote a big trieste on fourth and fifth normal format, preemption models, work to do models, and process concurrency. I tend to do that when I see something that I've worked with in detail fly by. Anyway, rather than mail a 4 page document, suffice it to say there are some problems in the assumptions about "what concurrency is" built into the question itself. Consider: can you stripe the data that tells how you striped the data? Consider also, that the per transaction will go up only inter-process and not intra-process, and that an inter-transaction increase for a single client would require that client to break the request/response model defining the data streams as transactions in the first place. Finally, a transaction will require multiple datum to establish a relationship for a third normal format, and these requests can't be any better interleaved in a striped environment than not without changes to the process and kernel preemption models. Striping will buy you multiprocess improvements only. Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9504071832.AA20804>