So which part of the system needs to handle the concurrency?  Does FFS
need to be rewhacked, or what?

#define AUTHOR "Chris_G_Demetriou@NIAGARA.NECTAR.CS.CMU.EDU (Chris_G_Demetriou@NIAGARA.NECTAR.CS.CMU.EDU)"

/*
 * People who say "use disksort" are missing something: concurrency.
 * 
 * There's a lot of literature out there, that's been put out recently,
 * about the fact that exposing I/O concurrency to the OS, and to the
 * hardware wins significantly.
 * 
 * In the recent SOSP paper that my group did, we saw some occasionally
 * quirky -- but always better -- performance by exposing more concurrency
 * to the drive(s).  (The one particular case i can think of, that i
 * think was mentioned in that paper was a case where we were doing grep
 * string * for the files in one manual section, and disclosing our future
 * file accesses to the OS via hints, so that it would prefetch the data.
 * w/ one request outstanding at the drive, we got horrible performance,
 * with many, we got great performance...  turns out that the layout
 * of the files on-disk -- done by the FFS -- was EXACTLY OPPOSITE
 * optimal, because of the fact that the files were added to the
 * directory in almost reverse order.)
 *
...
 * chris
 * 
 */

#undef AUTHOR	/* "Chris_G_Demetriou@NIAGARA.NECTAR.CS.CMU.EDU (Chris_G_Demetriou@NIAGARA.NECTAR.CS.CMU.EDU)" */




				--*greywolf;
--
I'm really a software toolsmith and a musician by trade, but nobody really
needs a software toolsmith much, and the music industry is so cutthroat
that it would probably do me in.  So I do systems administration on the
side as a hobby.  Funny that my hobby finds more work than either of my
professions...