[Discuss] ZFS

[gaf at blu.org (Jerry Feldman)]

On 10/05/2011 10:18 AM, Edward Ned Harvey wrote:
>> From: discuss-bounces+blu=nedharvey.com at blu.org [mailto:discuss-
>> bounces+blu=nedharvey.com at blu.org] On Behalf Of Jerry Feldman
>>
>> Btrs is supposedly a better
>> file system than ext4, but, it is still somewhat immature on Linux. I
>> think that if one of the major distros decides to use it as a default,
>> it may eclipse ext4. But, as Tom says, you need to look at your usage
>> patterns.
> The main advantage, and disadvantage of btrfs versus ext4, is the ability to
> do snapshots.  While this is a really useful feature, reducing your
> dependency on backups and making it easier to get good backups,
> copy-on-write inherently leads to fragmentation.  I don't recall if the
> defrag feature is implemented yet on btrfs.  I know it's not implemented on
> ZFS.
>
> Also, btrfs and ZFS do filesystem checksumming.  In ext4, whenever a disk
> gives you an undetected bit error, it goes undetected and uncorrected,
> leading to silent bit rot.  If you're replicating or backing up data at the
> time, or basing calculations on the wrong data, then everything derived from
> the bad data is also bad and undetected.  If you think that's not a problem,
> it's only because you've always used ext4 or something without checksumming
> up till now, and you haven't seen the logs on a system that does filesystem
> checksumming.  On the typical ZFS fileserver that I currently support, I
> would say it corrects one checksum error every approx 12-18 months.  It's
> like playing a lottery to lose everything...  Sure it's not likely to
> happen, and even if it does happen, you probably won't hit the "jackpot"
> (all useful data destroyed silently and undetected.)  But it's a lottery
> that you don't want to play.
>
> In the case of btrfs versus ext4, the immaturity is a real consideration.
> While the FS is stable, there are a lot of important features not yet
> implemented - like quotas for example.  And as a result of lack of quotas -
> each snapshot is read/write, cannot be made read-only.  They are currently
> working on implementing quotas, and the ability to send a snapshot from one
> system to another (replicate/backup a filesystem incrementally).  Of all
> features, this is probably the one most valuable feature I use from ZFS.  So
> I'm very eager for btrfs to be able to do the same.  We formerly used an
> rsync nightly backup, where rsync would run 10 hours every night scanning
> the filesystem for changes to send.  Now the incremental snapshot sends...
> Average 7-12 minutes.  Because of the snapshots, it already knows all the
> blocks on disk that have changed, and it doesn't need to search for them.
>
> There's another difference - ext4 takes a long time to format a large
> device, while mkfs.btrfs is essentially instant.  And ext4 can expand the
> filesystem on the fly (resize2fs) but cannot shrink while the filesystem is
> mounted.  Btrfs is able to both expand and shrink while mounted.
>
>
Undetected bit errors certainly can cause problems. Years ago when
running on a head-per-track disk, we backed up after a batch run, and
restored before the next run. At some point somehow a horse appeared in
a personal trust file :-). After many hours of looking at dumps and
stuff, I found the offending bit. This caused me to rant about Burroughs
systems.

While I don't think the time to create a file system is really a
significant issue because it is essentially a one time shot. Certainly
the ability to resize a filesystem online while the filesystem is
mounted is an important feature.

-- 
Jerry Feldman <gaf at blu.org>
Boston Linux and Unix
PGP key id:3BC1EB90 
PGP Key fingerprint: 49E2 C52A FC5A A31F 8D66  C0AF 7CEA 30FC 3BC1 EB90