Date: Sat, 12 Apr 2003 18:22:56 +0200 From: Marko Zec <zec@tel.fer.hr> To: Alfred Perlstein <bright@mu.org> Cc: freebsd-stable@freebsd.org Subject: Re: PATCH: Forcible delaying of UFS (soft)updates Message-ID: <3E983D60.CFCB950A@tel.fer.hr> References: <3E976EBD.C3E66EF8@tel.fer.hr> <20030412033307.GR30960@elvis.mu.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Alfred Perlstein wrote: > * Marko Zec <zec@tel.fer.hr> [030411 19:01] wrote: > > > > When enabled, the extended delaying policy introduces some additional > > changes: > > > > - fsync() no longer flushes the buffers to disk, but returns immediately > > instead; > > This is really the only bad thing I can see here, what about introducing > a slight delay and seeing if one can coalesce the writes? Is this > part really needed? Making fsync() not work is a good way to make > any sort of userland based transactional system break badly. The motivation for hacking fsync() was in preventing some common tasks from spinning up the disk. One example is the vi editor, which if I'm not mistaking calls fsync() on the same moment as one starts modifying the file, not to mention on explicit :w. If the disk would start spinning every now and than, the whole patch would than become pointless... Nevertheless, the fact that the modified fsync() just returns without doing anything useful doesn't mean the data will be lost - it will simply be delayed until the next coalesced updating occurs. Marko
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3E983D60.CFCB950A>