--On Wednesday, January 20, 2010 1:16 AM +0100 "O. Hartmann" <ohart...@mail.zedat.fu-berlin.de> wrote:
This could end in a bad situation, where one process writes a files, say with some arbitrary stuff and another successing process is intended to read this file. even if the processes are run serial, those 'delays' could break the chain! The delay situation in a development environment is harsh, but in other circumstances it could develop very bad.
The read occurs from the write cache. Thus the reader would see the writers data (given the usual POSIX semantics). ZFS delayed writes are handled by the cache/ZIL layers, reads and writes go through these layers. The ZIL is normally written very quickly.
ZFS actually (through the ZIL) has better journalling and recovery semantics than most journalling filesystems.
I see this strange behaviour now for several weeks, something essential has changed in the code, I guess. On UP boxes the situation is worse sometimes, on SMp boxes with lots of RAM ( 8 and 16 GB and 4 or 8 CPU cores) it is still bad. I have a server that acts as a 'rsync' backup system gathering data from satellite servers from time to time. Since this problem of slowness occured, this 4-core 8 gig RAM box crawls for minutes. Even when X11 is disabled working on console is 'bumpy': terminal out slows down, mouse pointer jumps etc.As I wrote, the same on a 8 core/16 gig box, but not that harsh. _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
_______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
