"Stephen C. Tweedie" wrote:
> > I'm planning on using raw disk access for my own user-level
> > stable queue (yes, I'm rolling my own MQ-Series-like stuff, yech).
> > I gather from
> > http://www.uwsg.iu.edu/hypermail/linux/kernel/9910.2/0930.html
> > that this is already in 2.3.
> > The question is - when write() returns, what has really happened?
>
> It is absolutely guaranteed to have been written to persistent
> storage (unless you've got a disk configured with write-behind,
> which lies about write completion).
Thanks.
While we're on the subject of raw I/O, I'd like to know whether using
it wrong can cause low throughput.
My server application implements a set of stable queues on a raw partition.
These naturally roll back to the last checkpoint if the system crashes between
checkpoints.
The app accepts requests from clients, stores them in a stable queue,
and returns completion status to the client after each checkpoint.
It maintains its own page cache for the partition in user space,
and a worker thread periodically flushes all dirty pages, in page order,
queue metadata last, to raw disk to perform a checkpoint.
(It also flushes individual pages to disk occasionally if it needs to free up space.)
Is there anything inefficient about a worker thread sequentially
using write() to a raw device on a bunch of areas in page order?
For instance, the 'wait for write completion' prevents me from
issuing the next write, and might lead to some noticable amount
of idle time on the disk.
I kind of wish there was a flavor of raw I/O that used fsync()
to do the 'wait for write confirmation'. That way, my individual
write()'s could be issued with less dead time between them.
For now, the only thing I plan to do about this is to combine adjacent
writes into larger writes, but I do wonder about dead time.
Thanks,
Dan
-- Entia non sunt multiplicanda praeter necessitatem.- 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/
This archive was generated by hypermail 2b29 : Tue May 23 2000 - 21:00:15 EST