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 Tom Metro
> 
> > Neither ZFS nor OCFS2 can compete for raw performance with ext4...
> 
> Reference?

I was going to comment on that - and then I wasn't - and now I am.
Minimally.

In all of the above (and btrfs) there are different architectures and very
efficiently written code.  This means each design will outperform the others
in certain specific ways.  Take for example, zfs and btrfs both do copy on
write to support snapshots, which means they have very efficient mechanisms
for remapping logical blocks to physical blocks.  Very efficient, but
nonzero.  Which means (a) if you're not doing any snapshots, then the block
remapping is wasted overhead in zfs and btrfs, so for certain types of
operations, ext4 would perform better, due to less overhead.  and (b) zfs
and btrfs are both able to perform write aggregation, which ext4 can't.
Which means both ZFS and btrfs will outperform ext4 for small random writes
(async mode) by an order of magnitude or two - by remapping a bunch of small
random writes into a single large sequential write.  (I measured 20x-40x.)
ZFS does storage multitiering, which means you can use things like SSD's to
accelerate even the small sync mode writes (a factor of 5x-10x) and you can
use large SSD's etc to extend your cache instead of buying infinite ram.
But in the typical use case, btrfs and ZFS have snapshotting enabled, and
automated snapshots being created and destroyed, so if you've got a large
sequential file with a bunch of random writes taking place inside it (for
example a database, or an EDA simulation) then btrfs and zfs will perform
those writes much faster than ext4...  But the end result is file
fragmentation, which means ext4 could sequentially read the file back much
faster.  Again, by an order of magnitude or more.

The list of architectural differences, and resultant performance
differences, could go on for the length of a book.

It's unfair and inaccurate to make the generalization that one is better or
faster than the other.  They're each better in specific cases.  Know the
architecture gains and losses of each one, and use the best tool for
whatever job you're trying to do.




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