ZFS, Sun’s latest filesystem, got a well deserved fame because of it’s ease of use and powerful features.
Those of you who have actually already setup a software RAID with Solstice DiskSuite will truly appreciate how much simpler Sun made it with ZFS. The concepts of volume management and filesystems behind ZFS are not new, but Sun brought an unprecedented ease of use administration to those.
To understand Sun’s ZFS philosophy, you have to understand that it is built over two concepts : pools and filesystems. Let’s see what they are.
When you work with ZFS, you group the disks in pools over which you will extend your filesystems. Those pools implement the organization of physical disks (mirrors, RAID, with or without spare disks and so on).
You can create pools, add / remove disks, scrub pools (check integrity), manage faulty drives / hot spares … all of this with single line commands and on “hot” pools (i.e with mounted filesystems).
Check the manual page of zpool , the command which lets you manage pools.
Filesystems extend over pools. They are not space-limited at creation (as opposed to disk partitions or slices), so all of the filesystems on a pool will share the volume available on this pool. You’ll never have to think about growing or shriking a filesystem again. If you need more space, just plug more disks and add them to the pool.
But you can of course implement quotas or reservation as needed.
So ZFS provides you with quotas and reservation, but also with snapshots and compression of filesystems.
Snapshots are read-only copies of a filesystem at the moment you take the snapshot : they won’t change, whatever the modifications you could bring to the original filesystem and they occupy only a small amount of space because, as long as the original filesystem remains untouched, no data block is copied. Further modifications will only provoke the copy of the changed data blocks.
Check the manual page of zfs, the command which lets you manage ZFS filesystems.