Jamie Lokier writes ("Re: [Qemu-devel] [PATCH] ide.c make write cacheing
controllable by guest"):
> I agree it's a bit ambiguous. My understanding is that _increases_ in
> size are included, by convention as much as anything, since the larger
> size is necessary to retri
Ian Jackson wrote:
> Jamie Lokier writes ("Re: [Qemu-devel] [PATCH] ide.c make write cacheing
> controllable by guest"):
> > I'm imagining that fdatasync() will flush the necessary metadata,
> > including file size, when a file is extended. As would O_DSYNC
Jamie Lokier writes ("Re: [Qemu-devel] [PATCH] ide.c make write cacheing
controllable by guest"):
> I'm imagining that fdatasync() will flush the necessary metadata,
> including file size, when a file is extended. As would O_DSYNC.
Do you have a reference to support this s
Ian Jackson wrote:
> > Ideally, the host would provide variation of fdatasync() which flushes
> > data to hard storage in the same way that kernel filesystem journal
> > writes can do, and Qemu would use that.
>
> Another question arises: do we want bdrv_flush to call (eventually)
> fsync or fdata
Jamie Lokier writes ("Re: [Qemu-devel] [PATCH] ide.c make write cacheing
controllable by guest"):
> However, I notice that it tells the guest that data is committed to
> hard storage when the host has merely called fsync().
Yes, that's what fsync is supposed to do.
>
[To qemu-devel and Chris, I have started a thread on linux-kernel on
this topic. I've copied the first few paragraphs here, so you can see
what it's about since it's a response to a post here. But it's
largely off topic for Qemu, and on topic for linux-kernel, so I didn't
cross post lest linux-ke
On Mon, Feb 25, 2008 at 08:50:40PM +, Jamie Lokier wrote:
> On Linux (and other host OSes), fdatsync() and fsync() don't always
> commit data to hard storage; it sometimes only commits it to the hard
> drive cache.
That's a filesystem bug IMO. People should be able to use f[data]sync
with so
Ian Jackson wrote:
Content-Description: message body text
> The attached patch implements the ATA write cache feature. This
> enables a guest to control, in the standard way, whether disk writes
> are immediately committed to disk before the IDE command completes, or
> may be buffered in the host.
