i have running ext3 with quota lvm acl support and samba,
with no problems on suse 9 , but i dont have trillards of files or files bigger than 2G to test.
The Story seems to be that filesystems arent implemented same good on every distro / kernels, so i was not able to implement xfs and samba on suse 9 , but i know this works with debian sarge ( cant remember the kernel ) . I have a few share partitions with reiserfs and acl which works very nice with suse 9.
Suse 9.1 seems to have major Problems with xfs.
( suse 9.1 is not a big shoot, you should only use it for needing kernel 2.2.6 features )
So i recommend to use ext3 as the best deal ( maybe dont i special cases, ie. large shares with millions of files here xfs is the better one )
VFAT is a simply outdated system, as the only thing which may make you happy that you can mount it under any win system, this might be helpfull
on small portable usb/firewire storages which can be used for backup in smaller filestores with samba.
Best Regards
Malcolm Baldridge schrieb:
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.
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.
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.
=MB=
-- To unsubscribe from this list go to the following URL and read the instructions: http://lists.samba.org/mailman/listinfo/samba
