zfs fs

I'm still learning about ZFS myself, but data integrity and easy manipulation of data sets, and ACLs seem to be the key factors.

A quick ddg for "Why is ZFS on FreeBSD awesome?" brought up lots of articles. https://www.reddit.com/r/sysadmin/comments/ntowf/whats_so_awesome_about_zfs/ seems to be a nice place to start as your question is asked, with lots of answers from sysadmins.

I'd be interested to hear some FreeBSD specific points of view as well. I believe there is an all things ZFS BSDNow episode as well.

*Edit just realized that link is 5 years old, so ZFS is even better than described in that thread.
 
There really isn't one specific feature. ZFS was the first---and is the most mature and most thoroughly tested---filesystem of this new generation of filesystems. It solves a whole bunch of problems that computer filesystems have had up until its introduction. For example, all computer filesystems have a limit to how much data they can store, and how large any one file can be. The amount of storage space a single disk can hold has increased very rapidy over time, making those filesystems' limits too restrictive. But ZFS was designed so that the limit on how much data it can hold (and how large a single file can be) is so great that its storage limits will only be reached long after we and our children are long dead. ZFS also addresses filesystem corruption by using copy-on-write and write transactions, so that sudden power loss doesn't damage the filesystem; addresses data corruption by giving checksums to each file so that corruption can be immediately detected and even repaired; and addresses storage limits by incorporating flexible logical volume management.
 
hajthem said:
... the most signifcant feature of zfs that brings all the hype about it
Click to expand...
Let me say in a short slogan what miker and ANOKNUSA already pointed at:

The 'killer feature' of ZFS is the fact that it is an anti-data-rot-filesystem.

(At least for me, who knows from own bad experience how disastrous single bit flips can be on conventional filesystems)
 
I suppose it depends on who you're asking but for me a major aspect is the fact that you can much more easily manage your data without risk of wasting diskspace. But to understand this you'd have to be familiar with the way FreeBSD worked with the UFS filesystem.

On a regular system running with UFS it's not uncommon to place /, /var, /usr, /home and /usr/local onto different slices. Or in other words: different partitions. This comes with a problem, because if you don't know what you're doing or if you miscalculate the amount of space you're going to use then you can easily risk ending up with (for example) 30gb worth of free space in /home but a 1gb shortage in /var (for example because a database in /var/db became much larger than you anticipated for).

If that happens then you got yourself a problem, especially if you can't easily take the system down to correct things. In the example above I suppose you might be able to move the database from /var/db onto /usr/local/var/db (to keep some bit of consistency) but it's not ideal.

But even if you can take the system down then it remains to be seen how easily you could resize your partitioning scheme.

So enter ZFS....

A ZFS pool contains all your data, and that data can get divided across multiple virtual filesystems. Although you're working with separated filesystems they all use the same amount of available diskspace. So there can never be an issue of having one filesystem running short of available space while another filesystem has an excess of free space.

So you still have all the advantages which separate filesystems provide (examples being applying quota's or keeping things mounted readonly, or maybe using noexec or nosuid) while all available diskspace gets distributed / shared equally.

Another advantage is that in the event that you do suddenly run out of available space then all it takes is adding more storage. Also something impossible with UFS: because although it's easy to add a new disk to your system you'd still be tied to your previously setup partitioning scheme.

And that's roughly the advantage.
 
ShelLuser said:
...in the event that you do suddenly run out of available space then...
Click to expand...

Have you actually experienced what happens when your system disk gets 100% full (0 byte free)?

On a ZFS system, rm fails, no space gets freed up:
Code: 
# rm <sometrashfiles>
error: Insufficient disk space
#

On an UFS system, rm just works as it should
Code: 
# rm <sometrashfiles>
#

(The ZFS system was PC-BSD, though. Its update manager managed to fill up the disk overnight so that there actually were zero bytes free. I had to delete a snapshot to free space so that rm worked again.)
 
I don't know why other people like it; that's their issue. And honestly, I haven't paid any attention to the "hype", but then I live in the world of storage and file systems and don't worry about marketing chit-chat. I don't find ZFS particularly awesome, just a well-integrated package.

Why do I use it at home? Because there are a few features I want, or more accurately: insist on.
  • RAID that is integrated with the file system: rebuilding unallocated space is not only a waste of time, it hurts performance, availability, and most importantly reliability.
  • RAID that can work with uneven disk sizes, and that can therefore be used to upgrade to larger disks without downtime.
  • On-disk checksums, because bit rot happens today.
  • Scrubbing, because finding disk errors early helps reliability, and makes administration more relaxed: fix problems before they become a crisis. My system has ample spare throughput to allow for good scrubbing.
These features are hard to find in a single file system, until you go the high end, to some very complex (and often expensive) offerings, which often won't work for small systems and a small number of disks. To some extent one can piece these features together (for example by using a separate RAID layer and a file system on top, and then do checksum in user-space with a daemon), but having it in a single integrated package works better (see rebuilding of unallocated space argument above), and more importantly for me it makes administration easier.

There are lots of other features (ACLs, snapshots, quota, multiple file systems in a single pool, caches and ZIL, ...) in ZFS that I don't happen to use. I might start using them in the future, but my home server is simple enough, it hasn't needed them (yet?). I also continue to use UFS for the boot file system and system disk (which I do have partitioned into about a half dozen file systems, but I don't find the problem ShelLuser describes above to be trouble, YMMV).

Matter-of-fact, there are really only two reasons I switched from OpenBSD to FreeBSD: (a) better wireless drivers, and (b) ZFS. And reason (a) has become obsolete now that I don't use my home server as a wireless AP any longer.

Oh, and the most important feature of ZFS: Unlike some other file systems, it doesn't murder your wife.
 
Integrity of the data has to be the main selling point of any file system. ZFS checks that box nicely with checksums and integrated mirror/stripe/parity features. Other ones that make it indispensable (for me):
  1. ZFS + auto-snapshots = awesome. Hrmm what did I change in my pf.conf last month? Let’s check!
  2. Boot environments (also awesome) are likewise enabled by ZFS/snapshots/clones.
  3. If you’ve ever used rsync for a filesystem of significant size (lots of files), then you’ll be blown away by zfs send/recv.
  4. Built-in compression. Multiple flavors, and set per FS. (gzip-9 on “archive” systems with compressible data, lz4 everywhere else.)
  5. ZVOLS work great for VMs
  6. Active development. Great things are on the horizon: faster scrubs, better (usable?) dedup...
Just my 2c.
 
Snurg said:
Have you actually experienced what happens when your system disk gets 100% full (0 byte free)?

On a ZFS system, rm fails, no space gets freed up:
Code: 
# rm <sometrashfiles>
error: Insufficient disk space
#

On an UFS system, rm just works as it should
Code: 
# rm <sometrashfiles>
#

(The ZFS system was PC-BSD, though. Its update manager managed to fill up the disk overnight so that there actually were zero bytes free. I had to delete a snapshot to free space so that rm worked again.)
Click to expand...

It's easy to avoid that situation. Just create a separate dataset named something like do-not-delete and set reservation=1G. That will keep 1 GB of space in the pool that no other dataset can use. If your pool reaches 100% used, just set reservation=1M on that dataset and you have space in the pool for delete/destroy operations. :)

I believe more recent versions of ZFS (possibly what's in 11.x?) do this automatically, by reserving a set amount of space in the pool for delete/destroy operations, to work around this issue.
 
You must log in or register to reply here.
Back
Top