ftp://linux.fnal.gov/linux/lts4x/i386/SL.documentation/RELEASE-NOTES-U1-x86-en says about SL4.1: " The ext2 and ext3 filesystems have an internal limit of 8 TB. Devices up to this limit have been tested. " Whoever tested a device up to the limit of 8 TB might have been able to make a partition that big. But one may also put a file system on an unpartitioned disk. There's a limit on the size of md software raid for individual members: " The maximum size disk that can be a member of an md software RAID set is 2 TB. The md RAID device itself can be larger than 2 TB. Devices have been tested up to 8 TB. " Steven Yellin On Thu, 1 Dec 2005, Troy Dawson wrote: > Ken Teh wrote: > > I've just installed SL4.1 on a dual opteron 6.4TB disk array system. This is > > my first disk array, so I'm full of questions. The disk array is configured > > as one large disk partition. At 5.6TB, it's larger (according to what I've > > read) than what ext3 can handle. So, I'm thinking of putting either JFS or > > XFS on the system. > > > > SL4.1's stock kernel does not have built-in JFS nor XFS support. But there > > is a contributed XFS rpm. Is this the preferred filesystem for large > > partitions? If so, why? > > > > I don't know the history of XFS, but I first encountered JFS in the late 80s > > when I worked on an AIX machine. Also, I read on the web that JFS has > > better performance than XFS. > > > > Comments?? > > > > Ken > > From the Scientific Linux 4.2 release notes > > o The current ext3 file system limit in Scientific Linux 4.2 > is 8 terabytes. The e2fsprogs package has been updated to > adhere to this file system limit. > > So it looks like if you use S.L. 4.2 you should be ok with 4.2. > (OK, so we haven't *officially* released it ... there is one file > driving us nuts, but what's in 4.2 is really what's going to be released.) > > But the question about the other stuff I think would be good to be > answered. But I'm not really the expert. > > This is what I've been told. > > XFS - good for very large files > Reiser - good for lots of small files > > Well ... that's not very much information, but all I have at the moment. > > Troy > -- > __________________________________________________ > Troy Dawson [log in to unmask] (630)840-6468 > Fermilab ComputingDivision/CSS CSI Group > __________________________________________________ >