[sf-lug] filesystem for a 3TB external USB drive

[Shane Tzen]

Let me apologize first if the following seems flip, but based on my
personal and practical experience with large filesystems, you were
given pretty bad advice.

On Sat, Dec 17, 2011 at 11:34 AM, Sameer Verma <sverma at sfsu.edu> wrote:
> Any recommendations on a 3TB Western Digital external USB drive? Came
> natively with a NTFS. Access will be via Linux only and will be used
> for backup.

The only filesystem that I personally for "large" volumes is JFS.
I've run this in production for years with about 30TB total (anther
40TB in scratch disks) and the largest single volume being around 16TB
with about 90% utilization and had never had to go unexpectedly in a
panic into work to deal with some mysterious JFS issue.

As far as other filesystems, unless you want to play fast and loose
with your data:

ZFS (http://zfsonlinux.org/):
"Please keep in mind the current 0.5.2 stable release does not yet
support a mountable filesystem." - You've gotta ask yourself a
question: "Do I feel lucky?"  If you want ZFS, do it on Solaris.

BTRFS (http://en.wikipedia.org/wiki/Btrfs#No_consistency_check_and_recovery_tool):
"As of November 2011, the planned filesystem check program has not
been released. This means that it is currently possible to corrupt a
btrfs filesystem and lose all files if your machine crashes or loses
power on disks that don't handle flush requests correctly." - Isn't
that special?

XFS:
XFS on Linux is not XFS on SGI.  My personal experience with XFS on
Linux is that it's basically unusable.  Years ago, you couldn't run
the bridging code and XFS concurrently on Linux (lead to random kernel
panics).  Nevermind why the filesystem code should interact that badly
with the networking code...  Despite my bad experience with it
initially, I had a few years ago tried it again just to see, and there
was silent data corruption on disk.  While the filesystem itself
thought that everything was fine, we were able to demonstrate that
certain data that was kept on disk had somehow mutated without rhyme
or reason, much less any warnings.

EXT2/3:
"Are you crazy? The fall will probably kill you."

All else aside, just the fsck time alone on a large volume rules this
out.  Granted 3TB is on the small side of a large volume, if there is
ever an issue that you might have to fsck an volume, then your data is
effectively offline for hours upon hours.  I had tried an 8TB volume
with EXT3 once and had to migrate the data off (the write performance
had mysterious hit a cliff when we went above a certain number of
files/directories).

I don't have a whole lot of experience with EXT4.  So the only thing I
can say about it is that it's new yet to be proven in production
(personally).

Reiser:
Excuse the pun, but Reiser is effectively dead.  4 is unlikely ever to
make it into the mainline kernel.  I haven't played with 3 in ages,
but had plenty of problems back when I did.  I believe my remark back
then was, "The recovery tools are excellent.  But that's only because
you're very likely to need them."

NTFS-3g:
"NTFS-3G supports partial NTFS journaling, so if an unexpected
computer failure leaves the file system in an inconsistent state, the
volume can be repaired." - from http://en.wikipedia.org/wiki/NTFS-3G.
Again, how comfortable are you with regard to possibly losing your
backup data?