 |
 |
Andrew Hanushevsky <[log in to unmask]> writes: > 1) Remove the message synchronization call. Synchornization forces a > message to be written to the log file before the next message can be > written. This adds a lot of delay and can actually hang the server > if the disk fills up. Without the call, however, you will loose > messages if the server crashes. I think removing the call to fsync is actually ok, at least for Unix/Linux. XrdOucLogger ultimately calls writev(2) to write the message to the log file; since that's a syscall, the OS has the data when writev returns, and it will (eventually) write it to disk regardless of whether the process crashes, so long as the system doesn't fail in some way. The typical case where output does get lost on a process crash is when stdio is used, since stdio has its own userland buffers, which are lost when the process goes away--but that isn't the case calling a system primitive like writev. The only downside, as Greg pointed out to me, is that the log will be incomplete in the case of a system failure. If you want a "belt and suspenders" approach (or are worried about running xrootd on Windows on top of a POSIX emulation layer that buffers writev in userland), a simple-minded possibility would be to pace the calls to fsync so that it isn't called more than once per second (for example). -dan