> 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. > > 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 said, I strongly recommend using Richard > Elling's zilstat. He's posted about it previously on this list. It will help > you determine if adding a slog device will help your workload or not. > I didn't know about this script at the time of our testing, so it ended > up being some trial and error, running various tests on different > hardware setups (which means creating and destroying quite a few pools). > > -Greg
How about the bug "removing slog not possible"? What if this slog fails? Is there a plan for such situation (pool becomes inaccessible in this case)? -- Roman -- This message posted from opensolaris.org _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
