Failed writes to block devices don't report an error

[Chris Johns]

On 24/06/10 2:08 AM, Arnout Vandecappelle wrote:
>
> 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
> filesystem.
>

It is not a small undertaking. I wanted to put on the record what we 
should aim at and to justify the selection of 1.

> [snip]
>
>>> 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 :-)
>

If you are using the DOSFS it may pay to check if it has hold of a 
buffer that may not be flushed. I think there are paths that can result 
in it holding a buffer. The sync call currently does not touch the file 
systems.


Chris