On Aug 22, 2009, at 5:21 PM, Neil Perrin <Neil.Perrin@xxxxxxx> wrote:
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
Async used to be the default behaviour. It must have been a shock to
users when suddenly NFS slowed down when synchronous became the
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
your previously hardware was asynchronously - but with no risk of
Of course the hardware is different so it's not really apples to
There was a thread not too along ago either on the xfs mailing list or
mysql mailing list that talked about the Intel X25-E and it's on board
cache. The cache ignores flushes, but isn't persistent on power
failure. Pulling the drive during a sync write caused data corruption.
You can disable the write back cache of these, but the performance is
no where near as good with it disabled.
zfs-discuss mailing list