PATCH: Forcible delaying of UFS (soft)updates
Marko Zec
zec at tel.fer.hr
Sat Apr 12 09:23:21 PDT 2003
Alfred Perlstein wrote:
> * Marko Zec <zec at 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
More information about the freebsd-fs
mailing list