Messages in this thread |  | | | Date | Mon, 17 Dec 2001 12:38:09 -0800 (PST) | | From | Andre Hedrick <> | | Subject | Re: O_DIRECT wierd behavior.. |
| |
You are asking for something that Linux is not capable of doing. There is no means to send and error back from the disk flush to the fs/appilcation period. The current 2.4 can not even find the partition when send an error back up to the block layer. 2.5 has a chance, but currently none have the ablitity to notify or flush disk cache and recover of there is a flushcache error.
Therefore it is potential a preferred model to preserve the entire request for a retry than to do a partial validation of an incomplete attempt.
On Mon, 17 Dec 2001, Joel Becker wrote:
> On Mon, Dec 17, 2001 at 11:59:56AM -0800, Linus Torvalds wrote: > > On Mon, 17 Dec 2001, Joel Becker wrote: > > > /* Smart program handles partial writes */ > > > write(100k); = 50k > > > write(remaining 50k); = -1/ENOSPC|EIO|etc > > > > We do this, if the error is "hard". And "fatal" implies hardness, so we're > > ok here. > > Right. "hard" is also synonymous with "non-transient". > > > > /* Dumb program doesn't handle partial write */ > > > write(100k); = 50k > > > close(fd); = -1/EIO > > > > But we're not doing this. > > IMHO we should be, and not just to comply with the letter of > SUS/Unix98. SUS specifies this behavior because a synchronous write() > can return after copying data to the buffer cache. However, the EIO can > happen later when the buffer cache is trying to flush to disk. The only > way for an application to see this error is to either run O_SYNC or > receive it upon close().
Andre Hedrick CEO/President, LAD Storage Consulting Group Linux ATA Development Linux Disk Certification Project
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |