Discussion:
ZFS benchmark results
Michiel Buddingh'
2005-11-26 18:38:03 UTC
Permalink
I've installed Solaris today to play with Sun's new filesystem ZFS(*).
Logging UFS on SVM mirror ZFS using mirrored pool
extract[1] 10:23.05 min, 25% cpu 3:00.07 min, 93% cpu
rm[2] 6:44.15 min, 10% cpu 1:19.32 min, 86% cpu
cvs[3] 21:02.90 min, 15% cpu 3:46.19 min, 91% cpu
It looks like ZFS is *really* fast. And the administration is amazingly
simple. So if somebody wants to port a journaling filesystem (ZFS doesn't
use a journal really but is always consistent on the disk nevertheless)
ZFS looks like an attractive target.
I do however not know whether Sun's CDDL license permits that.
(*) http://opensolaris.org/os/community/zfs/
| "All operations are copy-on-write transactions, so the on-disk state is
| always valid."

Sounds like another way of saying "log-structured filesystem", and ZFS'
featureset and performance (notice the high CPU load) seem to confirm that.

That doesn't mean it's not interesting, of course, but it would be cautious
to see if ZFS performs similarly well when the disk is almost completely
full.

mvg,
Michiel
Alan Barrett
2005-11-27 10:45:36 UTC
Permalink
Post by Michiel Buddingh'
| "All operations are copy-on-write transactions, so the on-disk state
| is always valid."
Sounds like another way of saying "log-structured filesystem", and
ZFS' featureset and performance (notice the high CPU load) seem to
confirm that.
No, it's not a log structured file system. See page 11 of
http://www.opensolaris.org/os/community/zfs/docs/zfs_last.pdf for a
diagram showing what they mean by "copy-on-write transactions".

--apb (Alan Barrett)
Jed Davis
2005-11-27 16:52:08 UTC
Permalink
Post by Michiel Buddingh'
(*) http://opensolaris.org/os/community/zfs/
| "All operations are copy-on-write transactions, so the on-disk state is
| always valid."
Sounds like another way of saying "log-structured filesystem", and ZFS'
featureset and performance (notice the high CPU load) seem to confirm that.
ZFS does something not too dissimilar from reference counting[*], and
frees unused storage on a per-allocation basis when it becomes unused;
LFS uses a full-blown GC, frees storage whenever it seems reasonable,
and has to copy live data out of a segment (and all the ancestors of
that data, IIRC) in order to free the segment for new allocation.

(Hm. I don't know what ZFS does to resist fragmentation.)
Post by Michiel Buddingh'
That doesn't mean it's not interesting, of course, but it would be cautious
to see if ZFS performs similarly well when the disk is almost completely
full.
s/disk/storage pool/, since one can just toss in more disk space,
hardware permitting. Anyway, I suspect ZFS will be in some trouble if
the disk is very close to full, but less than LFS.


[*] Except that reference counts require overwritable storage, which
ZFS can't have for consistency reasons; it uses instead an
algorithm involving transaction group serial numbers to identify
which snapshots are within the lifetime of a deleted block.
--
(let ((C call-with-current-continuation)) (apply (lambda (x y) (x y)) (map
((lambda (r) ((C C) (lambda (s) (r (lambda l (apply (s s) l)))))) (lambda
(f) (lambda (l) (if (null? l) C (lambda (k) (display (car l)) ((f (cdr l))
(C k))))))) '((#\J #\d #\D #\v #\s) (#\e #\space #\a #\i #\newline)))))
Matthias Scheler
2005-11-29 18:20:18 UTC
Permalink
Post by Michiel Buddingh'
That doesn't mean it's not interesting, of course, but it would be cautious
to see if ZFS performs similarly well when the disk is almost completely
full.
I had exactly that concern when I first read about ZFS. But considering
current disk prices I'm not too worried.

Kind regards
--
Matthias Scheler http://scheler.de/~matthias/
Loading...