In article ,
Mike Tomlinson writes:
En el artículo , Andrew Gabriel
escribió:

I've worked with many hundreds of customers using ZFS, and none have
ever lost any data due to it.

A colleague, an experienced system admin, lost all the data on a large
Linux ZFS array when it refused to re-mount the zpool following a sudden
power loss. He was hampered by the lack of decent tools to diagnose the
problem.

I'm unconvinced that zfs is yet sufficiently mature and proven on Linux.

ZFS on Linux has lagged someway behind the Illumos based distros
and FreeBSD, but it is catching up. I wouldn't choose Linux to
host a dedicated ZFS fileserver yet, although lots of people
are running ZFS loads on Linux without problems. It's miles
ahead of btrfs which seems to have made little progress for years,
much to the anguish of the Linux distros who are struggling with
not having an Enterprise class filesystem.

ZFS on Linux will get there - more people are working on it than
on any of the other platforms, but if it's the main purpose of the
system, for now choose an OS where ZFS is the native filesystem,
i.e. Illumos based (OmniOS, Openindiana, Nexentastor, etc), or FreeBSD
(including FreeNAS).

About three years ago I had to choose a file system for a 24-drive array
(48TB total, mounted as a single volume). RAID5 was done in hardware on
the RAID chassis and the external presentation was as one large block
device. I considered ufs, ext3, ext4, xfs, zfs, reiserfs, and btrfs.

ufs, ext3 and ext4 were out of the question as they become horribly
inefficient at sizes over 8TB due to the large cluster size. We were
storing a lot of small files, which would have meant a lot of wasted
space.

zfs and btrfs I rejected (at the time) as too new and unproven, and
lacking in tools to repair filesystems with problems. zfs, though,
would have been highly attractive for its data-healing capabilities.
Today, I would seriously consider using zfs as the user base is f\ar
larger and thus, hopefully, most of the wrinkles will have been ironed
out.

zfs requires a lot of memory to work efficiently.

reiserfs I rejected as unproven and concerns about ongoing development.

That left xfs: stable, developed and refined over 20 years, a reliable
source (SGI), good diagnostic tools, fast, highly efficient with small
files, and well-supported under Linux, so I went with that, and so far,
so good.

This talk at LinuxTag a couple of years ago goes over the pros and cons:

http://www.linuxtag.org/2013/fileadm...lides/Heinz_Ma
uelshagen_-_Which_filesystem_should_I_use_.e204.pdf

or http://tinyurl.com/k3kngh3

Many customers have layered
ZFS on top of their expensive SAN storage arrays so they can tell when
data gets corrupted, which was something that previously usually went
unnoticed until it was too late to restore an uncorrupted copy.

Sickipedia could have done with that:

(from www.sickipedia.org)

quote
[...] earlier today we experienced a cascade failure on one of the
volumes on our SAN, a drive failed when the array was already rebuilding
to a spare - this took that particular volume offline - it has
effectively failed at this point with a 2 disk failure within the same
24hr period.

The end result of todays issue, as the data on the volume was corrupted
unrecoverably when we forced it back online, is that the data for your
two servers has been lost. Unfortunately the service you have, also
never included backups"
/quote

Not the brightest idea, forcing a failed array back into a volume...


--
Andrew Gabriel
[email address is not usable -- followup in the newsgroup]