Failed writes to block devices don't report an error
Arnout Vandecappelle
arnout at mind.be
Tue Jun 22 13:03:18 UTC 2010
Hoi all,
When you write to a file on a block device, failures of the device itself
don't result in an error of the write. That's because the bdbuf layer
caches the blocks that are written and does the actual writeback
asynchronously after some time. At that point, of course, it's impossible
to report an error because the write() call has already returned.
This behaviour can be pretty annoying, though. For instance, I'm logging
to an SD card. When the SD card is removed, the logging just continues
without any error at all...
I have a few ideas of how this can be solved but I'd like some feedback.
1. Make sure rtems_bdbuf_sync() returns an error if the write fails.
rtems_bdbuf_sync() is called when disks or files are sync'ed. It writes
back a block and waits for the writeback to finish. Currently, it always
returns successfully but we could put error detection code in here.
2. Mark blocks as error and do synchronous writes for error blocks. After a
block is written it is not flushed from the cache, but remains there for
future accesses. We could mark the block as 'error'. On the next write to
that block, we write immediately instead of going through the cache. That
allows us to report any error occuring at that time.
3. In the filesystem (dosfs) add a mount option that makes sure that all
writes are done synchronously, i.e. they use rtems_bdbuf_sync() rather than
rtems_bdbuf_release_modified(). This of course relies on #1 so
rtems_bdbuf_sync() returns an error.
4. In the block device driver itself (spi-sd-card.c in my case), detect that
the media is removed and take appropriate action. I'm not entirely sure,
though, what 'appropriate action' would be.
Regards,
Arnout
--
Arnout Vandecappelle arnout at mind be
Senior Embedded Software Architect +32-16-286540
Essensium/Mind http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint: 31BB CF53 8660 6F88 345D 54CC A836 5879 20D7 CF43
More information about the users
mailing list