Subject: Re: letting userland issue FUA writes
To: Joachim K?nig-Baltes <firstname.lastname@example.org>
From: Bill Studenmund <email@example.com>
Date: 03/17/2006 08:39:04
Content-Type: text/plain; charset=us-ascii
On Fri, Mar 17, 2006 at 09:43:04AM +0100, Joachim K?nig-Baltes wrote:
> Bill Studenmund wrote:
> > The problem is it's not the exact semantics for what I want. I want
> > FUA down to the array. Among other things, you can have an array that
> > has a Battery-Backed-up-Unit and will write FUA'd writes to the BBU
> > and just pass non-FUA through to the disks. Waiting for after the call
> > can't change that behavior. :-(
> Yes, understood.
> and later, Bill Studenmund wrote:
> > That was my thought. Or actually some write_with_flag and
> > writev_with_flag syscalls. One flag could fold in pwrite vs normal
> > write, and another flag could fold in FUA.
> Or add a "const void *buf" argument to fsync_range, not as general as
> with pwritev or adding syscalls, but perhaps less intrusive on the
I am unclear how this parameter would help. fsync_range() has a flags=20
parameter, so what does the buf pointer do?
Also, I feel like I'm repeating myself, but adding FUA to fsync_range() is=
too late to get "write this to disk with FUA" semantics; if the pages have=
already been written to disk, there's no way to go back and add FUA to=20
those writes. Given that some arrays handle (or can be configured to=20
handle) FUA different from non-FUA, we need it on those writes.
Also, with FUA, you really want write-through caching as opposed to
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)
-----END PGP SIGNATURE-----