deciding UFS vs ZFS
DStaal at usa.net
Tue Jul 22 22:04:15 UTC 2014
--As of July 22, 2014 10:27:22 PM +0100, RW is alleged to have said:
> On Tue, 22 Jul 2014 14:16:06 -0400
> Daniel Staal wrote:
>> --As of July 22, 2014 1:33:05 PM +0100, RW is alleged to have said:
>> > On Mon, 21 Jul 2014 09:23:42 +0100
>> > krad wrote:
>> >> You seem to be getting away from your initial statement, which you
>> >> said zfs would make it worse, and journaled ufs. I really dont see
>> >> this being the case, yes there are scenarios where u will get a
>> >> screwed pool, but thats the case with any file system.
>> > Would you rather lose a third of your books, or a third of the
>> > chapters from all your books?
>> --As for the rest, it is mine.
>> I'd rather not lose any of it, not even a single period.
> Most desktops that have a lot of storage have it filled with
> multimedia, which is highly resistant to data rot, the OS can be
> reinstalled, this is not a significant issue to most people.
I switched to ZFS specifically *because* of the data rot in my multimedia
>> Which would
>> mean a filesystem that can monitor itself for health and integrity,
>> down to the individual file level, keep backups and changes, and
>> repair itself. Which is ZFS.
> I'm specifically talking about the case where a desktop PC is converted
> from JBOD to ZFS without any redundancy.
Ok, so not a single disk case, and a case *anyone* would recommend you
against. In fact, it's a case that every ZFS guide I've seen leaves out
because it's an idiotic idea to use ZFS that way.
>> The only real case of 'lose everything' under ZFS is if the disk goes
>> bad - in which case you'd lose everything under UFS as well, most
> When you lose some files from a directory it often renders others
> worthless, for example losing a third of the episodes of a TV series
> can be much the same as losing all of them. When a disk fails with UFS,
> the directories on the other disks are completely unaffected.
On the other hand, with a *sane* ZFS configuration, losing a single disk
out of ZFS pool doesn't even mean that the system as a whole notices: The
pool will continue to operate in a degraded state until you have the
opportunity to replace the disk. (Which - depending on your hardware - may
not even require you to take the machine down.)
Oh, and if you are going to argue that you'll lose disk capacity that way -
you might, some. Lukily disk space is cheap, and ZFS does a better job of
distributing it where it's needed. Your UFS-on-mountpoints system will
likely have a lot of 'wasted' space, allocated to mountpoints that do not
and will never need that space - but you can't be sure, and you'd have to
know ahead of time. ZFS on the other hand can hand that space over to
wherever you need it on the fly (you can even increase the total size of
the pool on the fly, by replacing or adding disks), and can compress (or
deduplicate, though there are performance penalties. On mostly-read data
like a media store it can be worth it though) data as it's being written.
So, depending on the data you may actually end up with more space.
(Unlikely with multimedia, but with more compressible formats it's quite
So, yes, if you set yourself up to lose data it's possible you'll lose less
data under a traditional UFS approach - but you won't be following any of
the ZFS guides I've seen, using any of the ZFS advantages, and aren't even
following *UFS* best practices. (Which would advocate for mirrored disks
or better if possible. It's just a lot harder to set up and use than under
ZFS, which makes it easy and nearly the default.)
Daniel T. Staal
This email copyright the author. Unless otherwise noted, you
are expressly allowed to retransmit, quote, or otherwise use
the contents for non-commercial purposes. This copyright will
expire 5 years after the author's death, or in 30 years,
whichever is longer, unless such a period is in excess of
local copyright law.
More information about the freebsd-questions