[ug-bosug] [Fwd: ZFS: 10 reasons ]

[SaiSatish Vedam]

Very nice 5 min overview.

--Sai

-------
(BTW, it was copied from: 
http://www.tech-recipes.com/rx/1446/zfs_ten_reasons_to_reformat_your_hard_drives).

I'm always surprised when Sun folks don't know how completely, 
earth-shatteringly cool ZFS is,
but I guess not everyone studied files systems in university.

Anyway, for your 'I-don't-have-time-to-click-that' convenience, here is 
the text:

   Here are 10 reasons to reformat your hard drives with ZFS.

   1. So easy your mom could administer it

   ZFS is administered by two commands, zpool and zfs. Most tasks
   typically require a single command to accomplish. And the commands
   are designed to make sense. For example, check out the commands to
   create a RAID 1 mirrored filesystem and place a quota on its size.

   2. Honkin' big filesystems

   How big do filesystems need to be? In a world where 640KB is
   certainly not enough for computer memory, current filesystems have
   reached or are reaching the end of their usefulness. A 64-bit
   filesystem would meet today's need, but estimate of the lifetime of
   a 64-bit filesystem is about 10 years. Extending to 128-bits gives
   ZFS an expected lifetime of 30 years (UFS, for comparison, is about
   20 years old). So how much data can you squeeze into a 128-bit
   filesystem? 16 exabytes or 18 million terabytes. How many files can
   you cram into a ZFS filesystem? 200 million million.

   Could anyone use a fileystem that large? No, not really. The topic
   has roused discussions about boiling the oceans if a real life
   storage unit that size was powered on. It may not be necessary to
   have 128 bits, but it doesn't hurt and we won't have to worry about
   running out of addressable space.

   3. Filesystem, heal thyself

   ZFS employs 256 bit checksums end-to-end to validate data stored
   under its protection. Most filesystems (and you know who you are)
   depend on the underlying hardware to detect corrupted data and then
   can only nag about it if they get such a message. Every block in a
   ZFS filesystem has a checksum associated with it. If ZFS detects a
   checksum mismatch on a raidz or mirrored filesystem, it will
   actively reconstruct the block from the available redundancy and go
   on about its job.

   4. fsck off, fsck

   fsck has been voted out of the house. We don't need it anymore.
   Because ZFS data are always consistent on disk, don't be afraid to
   yank out those power cords if you feel like it. Your ZFS filesystems
   will never require you to enter the superuser password for
   maintenance mode.

   5. Compress to your heart's content

   I've always been a proponent of optional and appropriate compression
   in filesystems. There are some data that are well suited to
   compression such as server logs. Many people get ruffled up over
   this topic, although I suspect that they were once burned by
   doublespace munching up an important document. When thoughtfully
   used, ZFS compression can improve disk I/O which is a common
   bottleneck. ZFS compression can be turned on for individual
   filesystems or hierarchies with a very easy single command.

   6. Unconstrained architecture

   UFS and other filesystems use a constrained model of fixed
   partitions or volumes, each filesystem having a set amount of
   available disk space. ZFS uses a pooled storage model. This is a
   significant departure from the traditional concept of filesystems.
   Many current production systems may have a single digit number of
   filesystems and adding or manipulating existing filesystems in such
   an environment is difficult.

   In ZFS, pools are created from physical storage. Mirroring or the
   new RAID-Z redundancy exists at the pool level. Instead of breaking
   pools apart into filesystems, each newly created filesystem shares
   the available space in the pool, although a minimum amount of space
   can be reserved for it. ZFS filesystems exist in their own
   hierarchy, children filesystems inherit the properties of their
   parents, and each ZFS filesystem in the hierarchy can easily be
   mounted in different places in the host filesystem.

   7. Grow filesystems without green thumb

   If your pool becomes overcrowded, you can grow it. With one command.
   On a live production system. Enough said.

   8. Dynamic striping

   On by default, dynamic striping automatically includes all deivces
   in a pool in writes simultaneously (stripe width spans all the
   avaiable media). This will speed up the I/O on systems with multiple
   paths to storage by load balancing the I/O on all of the paths.

   9. The term "raidz" sounds so l33t

   The new RAID-Z redundant storage model replaces RAID-5 and improves
   upon it. RAID-Z does not suffer from the "write hole" in which a
   stripe of data becomes corrupt because of a loss of power during the
   vulnerable period between writing the data and the parity. RAID-Z,
   like RAID-5, can survive the loss of one disk. A future release is
   planned using the keyword raidz2 which can tolerate the loss of two
   disks. Perhaps the best feature is that creating a raidz pool is
   crazy simple.

   10. Clones with no ethical issues

   The simple creation of snapshots and clones of filesystems makes
   living with ZFS so much more enjoyable. A snapshot is a read-only
   point-in-time copy of a filesystem which takes practically no time
   to create and uses no additional space at the beginning. Any
   snapshot can be cloned to make a read-write filesystem and any
   snapshot of a filesystem can be restored to the original filesystem
   to return to the previous state. Snapshots can be written to other
   storage (disk, tape), transferred to another system, and converted
   back into a filesystem.