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.
The bottom line is that for high COMMIT rate nfs workloads you need to do as Richard suggests and look into setting up a slog (separate intent log) on fast disks (or SSD) away from the rest of the storage pool. In spite of this, I would still recommend that you forward syslog traffic just for the sake of marshalling your resources for important work, rather than waste. -- paul _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
