From: Jeff Dike <jdike@ka...> - 2001-02-16 00:59:15
Sorry about that last message...
> I noticed that ubd doesn't do synchronous (i.e. O_SYNC) disk IO. This
> seems like a bug. Aren't block devices required to actually perform
> the IO once it is pushed to them? Apart from the psychological effect
> (confusion at the fact that 'sync' doesn't do disk IO :), things like
> write ordering are important for journalling filesystems as well.
At least that's my position - other people have other opinions.
Disk drives are allowed to cache writes and report that they've finished even
though the data hasn't made it to magnetic media yet, as long as they
guarantee that it eventually will. My position is that the host is a very
fancy caching disk drive and that I'm allowed to feed it writes and consider
them done when the IO request returns.
Having said that, I recognize that the host OS may be considered somewhat less reliable at ensuring that data hits the disk in the face of crashes, power outages, etc. So, if you were to put that patch under the control of a command line option, I would take it.
From: David Woodhouse <dwmw2@in...> - 2001-02-16 11:36:00
> Disk drives are allowed to cache writes and report that they've
> finished even though the data hasn't made it to magnetic media yet,
> as long as they guarantee that it eventually will. My position is
> that the host is a very fancy caching disk drive and that I'm allowed
> to feed it writes and consider them done when the IO request returns.
Linux currently ignores that fact of life and assumes that all drives it
ever comes into contact with have write caching disabled. There is no way
for a user/filesystem to flush pending writes if they're not actually on
the medium when the I/O request is completed.
Linux is arguably wrong in this assumption, so I don't see any great
problem with letting UML be as broken in this respect as normal Linux
kernels are. The bug lies in the Linux blkdev code, not the UML
implementation of a block device driver.