[libvirt] [PATCH] Extra filesystem options during backend filesystem mount.

[Harshavardhana]

Daniel,

    Thanks for the pointers, i will keep this mind as and when the problem
is fixed i will send a patch against those specific changes.

Regards
--
Harshavardhana
Z Research Inc http://www.zresearch.com/


On Fri, Jul 17, 2009 at 11:58 PM, Daniel P. Berrange <berrange at redhat.com>wrote:

> On Thu, Jul 16, 2009 at 08:24:09PM +0530, Harshavardhana wrote:
> > Hi Daniel,
> >
> > On Thu, Jul 16, 2009 at 7:46 PM, Daniel P. Berrange <berrange at redhat.com
> >wrote:
> >
> > > On Thu, Jul 16, 2009 at 06:06:25AM -0700, Harshavardhana wrote:
> > > > New option index added to support -o options for various netfs.
> > > > Currently added an option for glusterfs.
> > >
> > > What effect does it have  ? Or why do we want/need it
> > >
> >
> > 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.
>
> ACK, I see why you need this for the current releases of kernel/glusterfs.
>
> As & when this problem is fixed we'll need to either remove this, or
> provide a way to turn it off again. I don't think this is the kind of
> tunable that should be exposed in the XML, since this is really just a
> hack to work around a bug in a specific releases. Someone using libvirt
> has no way to decide whether the hack is needed or not, so making them
> set it in the XML would not be desirable. One possibility would be to
> have a config file /etc/libvirt/storage.conf for controlling certain
> options like this per host.
>
> 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/<http://search.cpan.org/%7Edanberr/>:|
> |: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505
> :|
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20090718/1f49f6ab/attachment-0001.htm>