Nope, wrong conclusion again. This large performance degradation has nothing whatsoever to do with ZFS. I have not seen data that would show a possible slowness on the part of ZFS vfs AnyFS on the backend; there may well be and that would be an entirely diffenrent discussion to the large slowdown the NFS induces compares to localFS for single threaded loads.
more inline. Constantin Gonzalez writes: > Hi, > > I haven't followed all the details in this discussion, but it seems to me > that it all breaks down to: > > - NFS on ZFS is slow due to NFS being very conservative when sending > ACK to clients only after writes have definitely committed to disk. Nope. NFS is slow for single threaded tar extract. The conservative approach of NFS is needed with the NFS protocol in order to ensure client's side data integrity. Nothing ZFS related. > > - Therefore, the problem is not that much ZFS specific, it's just a > conscious focus on data correctness vs. speed on ZFS/NFS' part. > So nope. Purely NFS related. Nothing ZFS related. > - Currently known workarounds include: > > - Sacrifice correctness for speed by disabling ZIL or using a less > conservative network file system. Disabling the ZIL means the backing FS fails to commit properly. The NFS protocol is cheated leading to client side integrity issue. With UFS, which has similar slowness to ZFS, we can fix the slowness by enabling the WCE. > > - Optimize NFS/ZFS to get as much speed as possible within the constraints > of the NFS protocol. Not possible. Nothing related to ZFS here and if NFS had ways to make this better i think it would have been done in v4. If we extended the protocol to allow for exclusive mounts (single client access) then, I would think that the extra knowledge could be used to gain speed... I don't know if this was considered by the NFS forum. > > But one aspect I haven't seen so far is: How can we optimize ZFS on a more > hardware oriented level to both achieve good NFS speeds and still preserve > the NFS level of correctness? > > One possibility might be to give the ZFS pool enough spindles so it can > comfortably handle many small IOs fast enough for them not to become > NFS commit bottlenecks. This may require some tweaking on the ZFS side so > it doesn't queue up write IOs for too long as to not delay commits more than > necessary. NFS is plenty fast in a throughput context (not that it does not need work). The complaints we have here are about single threaded code. > > Has anyone investigated this branch or am I too simplistic in my view of the > underlying root of the problem? > I'll let you be the judge of that ;-) -r > Best regards, > Constantin > > -- > Constantin Gonzalez Sun Microsystems GmbH, Germany > Platform Technology Group, Client Solutions http://www.sun.de/ > Tel.: +49 89/4 60 08-25 91 http://blogs.sun.com/constantin/ > _______________________________________________ > zfs-discuss mailing list > zfs-discuss@opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
