Re: ZFS benchmark results

Michiel Buddingh' <[email protected]> writes:

> On 2005-11-18, Matthias Scheler <[email protected]> wrote:
>
>> (*) http://opensolaris.org/os/community/zfs/
>
> From that document:
> | "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.)

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