> > So I wouldn't know it a commit to the buffer of a hard drive would be > considered by the zfs layer as a "secure" write when it received a COMMIT > request from the NFS layer. > > I'll do some testing when I've got some hardware to try back up some of my > analysis. At the moment I'm just trying to get a handle on a simple > methodology that might be of practical use when reviewing different specs > and deciding how large a stripe is required in order to sustain performance > requirements. >
The last time I did a quick-and-dirty check, I found that OpenSolaris and ZFS could make "better" use of the slog for NFSv3 commits, but they don't. Consider the following sequential write sequence: 1. NFS WRITE 0-32K (32K) 2. NFS WRITE 32K-64K (32K) 3. NFS WRITE 64K-96K (32K) 4. COMMIT 0-96K It is only at step 4 that any data is sent to the slog, which doesn't make very efficient use of the device. You could imagine an alternative approach where 32K writes were speculatively, and asynchronously, sent to the slog in advance of the commit message. This would hide the slog latency behind the wire latency. By the time the COMMIT message arrives all data could very well be in the slog already. Other integrated filesystem/NFS stacks may do this; I don't know. Of course, speculative use of the slog like this may increase CPU load and waste slog bandwidth on writes which never end up becoming synchronous. For some workloads it could be worth it. -- Kaya
_______________________________________________ storage-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/storage-discuss
