On 08/20/09 06:41, Greg Mason wrote:
Something our users do quite a bit of is untarring archives with a lot
of small files. Also, many small, quick writes are also one of the many
workloads our users have.
Real-world test: our old Linux-based NFS server allowed us to unpack a
particular tar file (the source for boost 1.37) in around 2-4 minutes,
depending on load. This machine wasn't special at all, but it had fancy
SGI disk on the back end, and was using the Linux-specific async NFS
option.
I'm glad you mentioned this option. It turns all synchronous requests
from the client into async allowing the server to immediately return
without making the data stable. This is the equivalent of setting zil_disable.
Async used to be the default behaviour. It must have been a shock to Linux
users when suddenly NFS slowed down when synchronous became the default!
I wonder what the perf numbers were without the async option.
We turned up our X4540s, and this same tar unpack took over 17 minutes!
We disabled the ZIL for testing, and we dropped this to under 1 minute.
With the X25-E as a slog, we were able to run this test in 2-4 minutes,
same as the old storage.
That's pretty impressive. So with a X25-E slog ZFS is as fast synchronously as
your previously hardware was asynchronously - but with no risk of data
corruption.
Of course the hardware is different so it's not really apples to apples.
Neil.
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
