Subject: Re: giant filesystem: which type to use?
To: Louis Guillaume <lguillaume@berklee.edu>
From: Chuck Swiger <cswiger@mac.com>
List: netbsd-users
Date: 01/16/2005 11:19:32
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.

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

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

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

> 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.

-- 
-Chuck