On Thu, Jul 31, 2008 at 01:07:20PM -0500, Paul Fisher wrote: > Stephen Stogner wrote: > > True we could have all the syslog data be directed towards the host but the > > underlying issue remains the same with the performance hit. We have used > > nfs shares for log hosts and mail hosts and we are looking towards using a > > zfs based mail store with nfs moutnts from x mail servers but if nfs/zfs > > combo take such a performance hit I would need to investigate another > > solution. > > > Syslog is funny in that it does a lot of open/write/close cycles so that > rotate can work trivially. Those are meta-data updates and on NFS each > implies a COMMIT. This leads us back to the old "solaris nfs over zfs > is slow" discussion, where we talk about the fact that other nfs servers > does not honor the COMMIT semantics and can lose data. I for one do > *not* want solaris nfs/zfs to behave in any way other than it does.
One more place where async variants of open(2) and close(2) would be very useful. NFS requires OPENs and CLOSEs to be synchronous, and for good reasons too. So then syslogd could do an async open of the log file and return to its event loop, then when the open completes it could write queued up log entries, then async close (or maybe async open, async write, async close, then return to the event loop). Such async syscalls can be emulated with threads. The same approach could help tar/cpio/... but there you have other sources of serialization, namely: compression. Nico -- _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
