Failed writes to block devices don't report an error

Arnout Vandecappelle arnout at
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.

Arnout Vandecappelle                               arnout at mind be
Senior Embedded Software Architect                 +32-16-286540
G.Geenslaan 9, 3001 Leuven, Belgium                BE 872 984 063 RPR Leuven
LinkedIn profile:
GPG fingerprint:  31BB CF53 8660 6F88 345D  54CC A836 5879 20D7 CF43

More information about the users mailing list