Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss] ZFS



> 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.




BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org