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.
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.
In this patch, by default buffering is off, which provides bette
