Hi!
Malcolm Baldridge wrote:
Quoting Mark Lidstone <[EMAIL PROTECTED]>:
ARGH! I'm wondering if airing thoughts about VFAT performance publicly
was a good idea.
I doubt VFAT's case insensitivity would be worth dealing with its terrible linear-search-time directory lookup methods.
The reason I suggested reiserfs (or ext3 with directory hashing) is to reduce the high costs of locating a directory entry within a directory of many (> 10,000) files.
msdos/vfat does not offer superior directory lookup times, and from my limited testing, neither does NTFS.
ext2/ext3 in stock configuration is also slow, though it appears very recent
kernels/ext2fsutils offer an FFS-like "directory hashing" option which needs
a format-time decision to be made upon setting up the filesystem.
You can enable it with tune2fs:
obelix:~# tune2fs -O dir_index /dev/hda3
See man tune2fs for more help.
<> I have no knowledge about XFS or JFS and how they compare. I know both are "industrial" filesystems brought down from the Ivory Towers onto the pipsqueak platforms.
As for "horror stories", well, each filesystem has had their respective
tales of misery and woe... ext3 had shocking and fatal dataloss bugs in the
adolescent versions of 2.4.x., and some RAID + reiserfs configs saw some
real wowsers as well. From bug reports/changelogs, I've seen similar tales
of woe for XFS and JFS if you trigger just the right combination of things.
>From my own experiences, things have matured and stabilised with reiserfs
and ext3 to the point where using either is fine for my purposes.
I had very bad experience with reiser: 4 servers installed with reiser, 4 server died due to filesystem corruption in a time that varied from two to six months (the last one had UPS, the others not). I reinstalled them with ext3: almost a year since I reinstalled the first: no problems.
In my experience: the fourth server (the one with the ups): Dual XEON 2Gb RAM, 3x36Gb scsi disk in raid-5 array smart array 5300, running squid: it was slower then (with reiser), than now (with ext3). I have only saw reiser to be faster when I delete a LARGE file (>1Gb). I'm going to test ext3 with the dir_index option.The decision comes down to:
1) Do you need quotas? If yes, you cannot use reiserfs. 2) Do you need ACLs? If yes, only ext2/ext3 has well-tested seamless support, though I think there are wildcat patches to bring this to XFS (and maybe others) as well. I'm not sure about the stability of this.
ext3 used with -O dir_index *MAY* provide better performance for large
directory list lookups, but I've never tested it. It requires Linux 2.6 for
starters for the kernel-side stuff to actually support it properly. grepping the linux 2.4 source shows no mention of hashing b-trees or
dir_index options for ext[23].
This is a RECENT addition to ext3, and I don't think the support actually exists within 2.4 yet. I've seen mention of "special backported patches" but this smells scarier to me than using filesystems which have been seamlessly integrated for over a year or so now.
So in terms of viable performance-driven alternatives, I see it being
reiserfs, xfs, or jfs.
vfat/dos isn't faster, even with case insensitive semantics, for directory
sizes of 20,000 or more.
I agree.
Ildefonso [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
-- To unsubscribe from this list go to the following URL and read the instructions: http://lists.samba.org/mailman/listinfo/samba
