[originally reported for ZFS on FreeBSD but Pawel Jakub Dawid
says this problem also exists on Solaris hence this email.]
Summary: on ZFS, overhead for reading a hole seems far worse
than actual reading from a disk. Small buffers are used to
make this overhead more visible.
I ran the following script on both ZFS and UF2 filesystems.
[Note that on FreeBSD cat uses a 4k buffer and md5 uses a 1k
buffer. On Solaris you can replace them with dd with
respective buffer sizes for this test and you should see
similar results.]
$ dd </dev/zero bs=1m count=10240 >SPACY# 10G zero bytes allocated
$ truncate -s 10G HOLEY # no space allocated
$ time dd <SPACY >/dev/null bs=1m # A1
$ time dd <HOLEY >/dev/null bs=1m # A2
$ time cat SPACY >/dev/null # B1
$ time cat HOLEY >/dev/null # B2
$ time md5 SPACY # C1
$ time md5 HOLEY # C2
I have summarized the results below.
ZFS UFS2
Elapsed System Elapsed System Test
dd SPACY bs=1m 110.26 22.52 340.38 19.11 A1
dd HOLEY bs=1m 22.44 22.41 24.24 24.13 A2
cat SPACY 119.64 33.04 342.77 17.30 B1
cat HOLEY 222.85 222.08 22.91 22.41 B2
md5 SPACY 210.01 77.46 337.51 25.54 C1
md5 HOLEY 856.39 801.21 82.11 28.31 C2
A1, A2:
Numbers are more or less as expected. When doing large
reads, reading from "holes" takes far less time than from a
real disk. We also see that UFS2 disk is about 3 times
slower for sequential reads.
B1, B2:
UFS2 numbers are as expected but ZFS numbers for the HOLEY
file are much too high. Why should *not* going to a real
disk cost more? We also see that UFS2 handles holey files 10
times more efficiently than ZFS!
C1, C2:
Again UFS2 numbers and C1 numbers for ZFS are as expected.
but C2 numbers for ZFS are very high. md5 uses BLKSIZ (==
1k) size reads and does hardly any other system calls. For
ZFS each syscall takes 76.4 microseconds while UFS2 syscalls
are 2.7 us each! zpool iostat shows there is no IO to the
real disk so this implies that for the HOLEY case zfs read
calls have a significantly higher overhead or there is a bug.
Basically C tests just confirm what we find in B tests.
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
