lkml.org 
[lkml]   [1999]   [Jan]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:50    [W:0.071 / U:0.440 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site