On Mon, 2006-07-24 at 17:51 -0400, Horst H. von Brand wrote: > > It all boils down to using the right tool for the job, ReiserFS was the > > right tool for this job. > > /One/ tool that did the job. Not "the" right one, perhaps not even the best > one.
Please, enlighten me as to what "the best" tool for the job would be in your opinion. Keep in mind this was around 2002-2003, which if I recall was before dir_index for EXT3 was around and stable too. > > If I recall correctly the database went from about 2million > > files to over 40 million in the span of just a few months. No one could > > have predicted that. I believe this database was on an 18GB SCSI drive, > > so even using 1K blocks wouldn't have worked. According to the mke2fs > > man page: > > > "-i bytes-per-inode > > This value generally shouldn't be smaller than the blocksize of > > the filesystem, since then too many inodes will be made." > > 18GiB = 18 million KiB, you do have a point there. But 40 million files on > that, with some space to spare, just doesn't add up. > > > The only other option at that time was to purchase Veritas backup > > ... or a larger disk... Why would we waste money purchasing larger disks just to _temporarily_ work around an EXT3 limitation? Even if we doubled the size of the disks (36gb) we would have run in to the same problem within months. I wouldn't consider this to be smart "planning ahead" as you put it. Its not just an inode issue either, its a performance issue. Benchmarks we ran with just 100,000 files making up 1GB of data, ReiserFS blew EXT3 out of the water where EXT3 was over 50% slower. If I recall the "database" was about 5GB at 25million files. When you have a limited window of time to do the backups in, performance is critical. http://fsbench.netnation.com/new_hardware/2.6.0-test9/scsi/bonnie.html (4th table down) -- Mike Benoit <[EMAIL PROTECTED]>
signature.asc
Description: This is a digitally signed message part
