[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH -V2 4/6] hw/9pfs: Implement syncfs
From: |
Stefan Hajnoczi |
Subject: |
Re: [Qemu-devel] [PATCH -V2 4/6] hw/9pfs: Implement syncfs |
Date: |
Tue, 1 Mar 2011 20:27:19 +0000 |
On Tue, Mar 1, 2011 at 6:02 PM, Aneesh Kumar K. V
<address@hidden> wrote:
> On Tue, 1 Mar 2011 15:59:19 +0000, Stefan Hajnoczi <address@hidden> wrote:
>> >> Please explain the semantics of P9_TSYNCFS. Won't returning success
>> >> without doing anything lead to data integrity issues?
>> >
>> > I should actually do the 9P Operation format as commit message. Will
>> > add in the next update. Whether returning here would cause a data
>> > integrity issue, it depends what sort of guarantee we want to
>> > provide. So calling sync on the guest will cause all the dirty pages in
>> > the guest to be flushed to host. Now all those changes are in the host
>> > page cache and it would be nice to flush them as a part of sync but
>> > then since we don't have a per file system sync, the above would imply
>> > we flush all dirty pages on the host which can result in large
>> > performance impact.
>>
>> You get the define the semantics of P9_TSYNCFS? I thought this is
>> part of a well-defined protocol :). If this is a .L extension then
>> it's probably a bad design and shouldn't be added to the protocol if
>> we can't implement it.
>
> It is a part of .L extension and we can definitely implement it. There
> is patch out there which is yet to be merged
>
> http://thread.gmane.org/gmane.linux.file-systems/44628
A future Linux-only ioctl :/.
>> Is this operation supposed to flush the disk write cache too?
>
> I am not sure we need to specify that as a part of 9p operation. I guess
> we can only say maximum possible data integrity. Whether a sync will
> cause disk write cache flush depends on the file system. For ext* that
> can be controlled by mount option barrier.
So on a host with a safe configuration this operation should put data
on stable storage?
>>
>> I think virtio-9p has a file descriptor cache. Would it be possible
>> to fsync() those file descriptors?
>>
>
> Ideally we should. But that would involve a large number of fsync calls.
Yep, that's why this is a weird operation to support, especially since
it's a .L add-on and not original 9P. What's the use-case since
today's Linux userland cannot directly make use of this operation? I
guess it has been added in order to pass-through a Linux internal vfs
super block sync function?
Stefan
- [Qemu-devel] [PATCH -V2 1/6] hw/9pfs: Add V9fsfidmap in preparation for adding fd reclaim, Aneesh Kumar K.V, 2011/03/01
- [Qemu-devel] [PATCH -V2 3/6] hw/9pfs: Use v9fs_do_close instead of close, Aneesh Kumar K.V, 2011/03/01
- [Qemu-devel] [PATCH -V2 4/6] hw/9pfs: Implement syncfs, Aneesh Kumar K.V, 2011/03/01
- Re: [Qemu-devel] [PATCH -V2 4/6] hw/9pfs: Implement syncfs, Stefan Hajnoczi, 2011/03/01
- Re: [Qemu-devel] [PATCH -V2 4/6] hw/9pfs: Implement syncfs, Aneesh Kumar K. V, 2011/03/01
- Re: [Qemu-devel] [PATCH -V2 4/6] hw/9pfs: Implement syncfs, Stefan Hajnoczi, 2011/03/01
- Re: [Qemu-devel] [PATCH -V2 4/6] hw/9pfs: Implement syncfs, Aneesh Kumar K. V, 2011/03/01
- Re: [Qemu-devel] [PATCH -V2 4/6] hw/9pfs: Implement syncfs,
Stefan Hajnoczi <=
- Re: [Qemu-devel] [PATCH -V2 4/6] hw/9pfs: Implement syncfs, Aneesh Kumar K. V, 2011/03/02
- Re: [Qemu-devel] [PATCH -V2 4/6] hw/9pfs: Implement syncfs, Stefan Hajnoczi, 2011/03/02
- Re: [Qemu-devel] [PATCH -V2 4/6] hw/9pfs: Implement syncfs, Aneesh Kumar K. V, 2011/03/02
[Qemu-devel] [PATCH -V2 5/6] hw/9pfs: Add open flag to fid, Aneesh Kumar K.V, 2011/03/01
[Qemu-devel] [PATCH -V2 6/6] hw/9pfs: Add directory reclaim support, Aneesh Kumar K.V, 2011/03/01
[Qemu-devel] [PATCH -V2 2/6] hw/9pfs: Add file descriptor reclaim support, Aneesh Kumar K.V, 2011/03/01
[Qemu-devel] Re: [PATCH -V2 1/6] hw/9pfs: Add V9fsfidmap in preparation for adding fd reclaim, Aneesh Kumar K. V, 2011/03/01