On Thu, Jul 16, 2009 at 7:46 PM, Daniel P. Berrange <berrange@xxxxxxxxxx> wrote:
Options could be required for filesystem to have few enhaced handling at the site where they will be under use. Correct approach for a configurable will be a new "XML" option in this case.
Regarding current patch:
This is required for the glusterfs to work properly with VM's. Right now there is a
problem/difficulty in using direct-io based mechanism in the fuse kernel module
when used with "XEN" in its "tap:aio" framework, we have seen xen vms hang over glusterfs or any fuse based filesystem due to fact that fuse module doesn't yet support "aio" with O_DIRECT internally as a kernel module. To have a work around fix we have to hardcode this value due to its usage in case of VM's.
We are currently fixing this problem by fixing directly O_DIRECT problem in fuse.
Which will be available in later releases for kernel.
So its just a glusterfs specific case.
On Thu, Jul 16, 2009 at 06:06:25AM -0700, Harshavardhana wrote:What effect does it have ? Or why do we want/need it
> New option index added to support -o options for various netfs.
> Currently added an option for glusterfs.
Options could be required for filesystem to have few enhaced handling at the site where they will be under use. Correct approach for a configurable will be a new "XML" option in this case.
Regarding current patch:
This is required for the glusterfs to work properly with VM's. Right now there is a
problem/difficulty in using direct-io based mechanism in the fuse kernel module
when used with "XEN" in its "tap:aio" framework, we have seen xen vms hang over glusterfs or any fuse based filesystem due to fact that fuse module doesn't yet support "aio" with O_DIRECT internally as a kernel module. To have a work around fix we have to hardcode this value due to its usage in case of VM's.
We are currently fixing this problem by fixing directly O_DIRECT problem in fuse.
Which will be available in later releases for kernel.
So its just a glusterfs specific case.
Normally direct-IO mode is something you'd let apps set on a per file
> @@ -670,6 +692,12 @@ virStorageBackendFileSystemMount(virConnectPtr conn,
> }
>
> if (pool->def->type == VIR_STORAGE_POOL_NETFS) {
> + if (pool->def->source.format = VIR_STORAGE_POOL_NETFS_GLUSTERFS) {
> + if (virAsprintf(&options, "direct-io-mode=1") == -1) {
> + virReportOOMError(conn);
> + return -1;
> + }
> + }
basis as they desire. QEMU / Xen both know todo this, so I'm not
convinced we should force it on for the whole mount point.
Regards,
Daniel
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
-- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list