Subject: Re: letting userland issue FUA writes
To: Bill Studenmund <wrstuden@netbsd.org>
From: Chuck Silvers <chuq@chuq.com>
List: tech-kern
Date: 03/15/2006 08:31:59
On Wed, Mar 15, 2006 at 07:28:49AM -0800, Bill Studenmund wrote:
> > this sounds like direct I/O, which I've talked about before (and which
> > I am just getting back to looking at recently ).  a new O_DIRECT open flag
> > on regular files will mean that the read/write should go directly from
> > disk to the application's address space without going through the
> > page cache.  if the new behaviour you're talking about it just for
> > raw disk devices, then we could interpret that flag to mean FUA on
> > VCHR vnodes.  or are you talking about FUA with regular files?
> 
> As above, I'm most interested in regular files.

ok, then I assume that you are only considering this FUA issue in the context
of direct I/O?  (were you planning on implementing direct I/O as well?)

 
> I'm not sure about O_DIRECT implying FUA. While I can think of apps that 
> want that, I am not sure if if there are or aren't apps that will want 
> O_DIRECT but not care about FUA.

yea, I was hoping to avoid dealing with the ambiguity.  but looking at the
open() manpage, I see we have the O_{,R,D}SYNC flags to describe the level
of persistence desired for the I/O, so I think we can use this to allow
specification of both FUA and non-FUA behaviour:

	
	no flags		kernel caching, FUA is irrelevant
	O_DIRECT		no kernel caching, no FUA
	O_DIRECT|O_*SYNC	no kernel caching, FUA

(I think O_*SYNC here would be either O_SYNC or O_DSYNC.)

-Chuck