Failed writes to block devices don't report an error

Arnout Vandecappelle arnout at
Wed Jun 23 16:08:57 UTC 2010

On Wednesday 23 June 2010 03:18:02, Chris Johns wrote:
> I see us needing both of these. Further the 'write' has:
>   "[SIO] If the O_DSYNC bit has been set, write I/O operations
>    on the file descriptor shall complete as defined by synchronized
>    I/O data integrity completion."
> This is an extension. I cannot find any further detail about the SIO
> extensions but to me it makes sense that we look at a standards base way
> of managing this. We have an AIO effort underway so we should consider
> the O_DSYNC flag.

 Agreed, but that's a lot more effort as it requires support all over the 


> > 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.
> This would be good to have. I see it being needed which ever way we go.
> I also see the following:
>   if (write(fd, buf, size) != size)
>     goto handle_error
>   if (sync_call(..) < 0)
>     goto handle_error
> in an application could be a work around until a more standard approach
> is made. I prefer this over the other suggestions.

...which is why I put it as the first one :-)


> > 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.
> I know Sebastian has something like this for USB devices. Maybe he can
> help here.

 As I feared, "appropriate action" turns out to be quite complex.  And 
detecting that the SD card has disappeared isn't trivial if the card detect 
pin isn't connected...

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