From the looks of it, ZFS administration is significantly simpler than administration of other complex file systems such as Solaris Disk Suite and Veritas Volume Manager. You can get a lot more done with fewer commands and the chance of making an error that is difficult to back out of is practically non-existent. On the other hand, it's still new to most Unix sysadmins and even those of us who have been working with other Unix file systems such as ufs or efs are going to have to devote some time to getting used to new vocabulary, commands and ways of thinking.

ZFS is without doubt a giant step forward in file system design and is without practical limitations. It features an impressive immunity to the kind of file system corruption that have hounded many of us for decades (refer to my recent problems with "freeing free blocks" crashes). Created by Jeff Bonwick's team at Sun, ZFS is already in use on various Linux, Mac OS X and FreeBSD systems.

128 bit means it can store 18 billion times more data than current 64-bit file systems with a 16 times 2 to the 64 byte maximum file system size which can comprise a single file if you want.

ZFS file systems are built on top of the concept of pools or "zpools" as they are referred to in ZFS. Instead of a volume manager sitting on top of multiple drives and adding a fair degree of complexity, ZFS joins devices into storage pools -- large data stores from which file systems can be built.

With ZFS, you don't have to carefully plan out your partitions and file systems. File systems can easily be grown as needed and new devices can be added at any time, enlarging the space available to all file systems.

Since ZFS is transactional (think "no fsck"), it is always consistent. With journaling, file system changes can be replayed as needed and no external tool is required to effect repairs. Damage caused by incomplete I/O operations just don't happen. Changes are either entirely complete or entirely ignored.

ZFS is also "self-healing". This means that all data, including metadata, are automatically checksummed. In addition, various levels of redundancy, including mirroring and ZFS' own version of RAID-5, called "RAID-Z". If a bad data block is detected, ZFS gets the correct data from a copy and repairs it.

ZFS also provides both file system snapshots and clones. Snapshots are read-only file system copies that actually use no disk space until the original file systems change in some way. Think about snapshots as providing extremely efficient recovery if you run into a problem with complex system changes. Clones, on the other hand, are identical copies of the original file systems.

To work with ZFS, you will need to get used to the various zpool and zfs commands. For example, "zpool create mypool c1t0d0" creates a storage pool on a single disk drive and a file system named "zpool". In addition, the file system is automatically mounted as /mypool. That's a lot to accomplish with a single command. You can then create additional file systems within this file system if you are so inclined. The command "zpool create mypool c1t0d0 c1t1d0" creates a pool using two disks and stripes data across the drives. Again, the file system and mount point are also called "mypool". To create a mirror instead of striping, you would only need to add the word "mirror" to the command -- zpool create mypool mirror c1t0d0 c1t1d0.

There are many other tricks you will need to learn before setting up and managing ZFS file systems will become second nature. You will want to know how to set up RAID-Z systems, offline disks, add disks to pools, replace disks in pools, destroy pools, share ZFS file systems, set disk quotas, work with snapshots and quotas, etc. After a two day class on ZFS, I was astounded at how easily file systems could be created, changed and managed with a series of zpool and zfs commands.

ITworld.com

• Email
• Print
• Share
  • Slashdot
  • Digg
  • Stumble
  • Reddit
  • Newsvine