Messages in this thread | | | Date | Mon, 25 Jan 1999 13:05:42 -0500 (EST) | From | "Benjamin C.R. LaHaise" <> | Subject | Re: Should raw I/O be added to the kernel? |
| |
Hello!
On Mon, 25 Jan 1999, Stephen C. Tweedie wrote:
> Absolutely, but that's not the point: the point is that the Unix API > does not allow applications to specify such a partial order on IO. Raw > IO, O_SYNC and friends, and fsync() are about all an application can > use.
A clever implementation of the API should be almost enough for most apps' needs: I think that fsync should flush the buffer associated with the file and place an io ordering marker in the queue. Once all associated buffers have finished flushing, fsync returns either success or EIO. The application then knows that an error occurred on one of the blocks written between fsync()s. Of course, with the way ext2 currently implements fsync(), this isn't terribly efficient, but here's a suggestion (one I just started playing with this weekend): make the cache of indirect blocks associated with an inode a virtually indexed cache a la page cache rather than using the buffer cache. I'm going about this by first abstracting the page cache into a virtual object cache. For this to be truely useful, it'll require the underlying block io scheme to be leaner (the 'think of buffer_heads as io requests' plan). This is just a little brain dump at present...
-ben
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |