Chuck Swiger wrote:
> Louis Guillaume wrote:
> 
>> Say, hypothetically, I needed a 5TB filesystem for a busy fileserver.
>>
>> What kind of filesystem would be best?
> 
> 
> Your question isn't specific enough to have a single best answer.
> 

Ok. I was trying to be as vague as possible to perhaps get a sense of 
what was out there in general. I think you covered it below too. But I 
can give some hypothetical specifics...

> How many clients are connecting, via which protocols, and what does the 
> network topology look like?

Let's say 1000 users connecting via one of AFP/CIFS/NFS. The contents 
are users' home directories. The idea is to have the users' data in one 
logical unit, so there isn't a requirement of "mounting" the appropriate 
server to get at each others' stuff. The network (10/100) would be 
heavily sub-netted ip4, so broadcast traffic is at a minimum.

> 
> What are the requirements for RAID, hot replacement/sparing, and backups?
> 

This I would think is transparent to the discussion here. I'm talking 
filesystem, rather than physical/logical disk unit.

> If you had to pick one or two out of "performance", "reliability", and 
> "cost", which of these criteria is more important to you?
> 

Being that this is hypothetical, of course we will pick "performance" 
and "reliability".

>> What are the stable options out there for NetBSD?
> 
> 
> There is a new version of the Berkeley FFS called UFS2 which supports 
> much larger filesystems.  I have seen limited discussion and bug reports 
> on FreeBSD lists about multi-terabyte filesystems, and people trying 
> filesystems larger than 2TB tend to run into serious problems (data 
> corruption, system panics) and unreasonable fsck times & fsck resource 
> usage that are being worked on now.
> 
> I would not expect a 5TB filesystem to be stable on FreeBSD today.
> 
> I can't recall seeing any discussion of multi-terabyte filesystems on 
> the NetBSD mailing lists recently.  I would not assume that NetBSD can 
> handle a 5TB filesystem reliably at this time, either, although anyone 
> with real-world experience is welcome to provide better information than 
> I have.
> 
>> Which filesystem type handles the "biggest" needs?
> 
> 
> In theory, or in practice?  The theoretical limits of UFS2, or Apple's 
> HFS+ Extended, Linux's ext3, and so forth are huge.  However, if trying 
> to fsck a multi-terabyte filesystem means that fsck's memory usage 
> doesn't fit in 2 GB of RAM and thus won't run on a 32-bit platform, the 
> filesystem isn't usable in practice!
> 
> You ought to be looking towards NAS or SAN platform solutions from 
> Auspex, EMC, NetApp, maybe Apple's new Xsan, which involve products 
> intended for that kind of requirement.
> 

And I certainly would look to this type of platform/solution. But the 
way I understand SANs is that these devices provide Logical Units for 
use by connected servers. If we connected a file server, we would still 
have to build a filesystem using one or more LUNs on the SAN.

The big question is:

In *practice*, what is the largest reasonable (stability-wise) 
filesystem size for each of FFS, FFSv2 (aka UFS2), LFS?

Also - are ext3, IBM's jfs, HFS+ or others supported on NetBSD? I 
thought we were limited to FFS v1 or v2 and LFS.

 From what I can tell, it seems likely that the disk will have to be 
split up into several decent-sized filesystems, each mounted separately.

Thanks,

Louis