deciding UFS vs ZFS

[Daniel Staal]

--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 
files.   ;)

>> 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
>> likely.
>
> 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 
possible.)

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