Are you going to apply this to mainline?. Was just wondering if you have any other concerns so that i could work on those if at all there are other better ways you would have.
Thanks
--
Harshavardhana
Gluster - http://www.gluster.com/
On Sat, Jul 18, 2009 at 9:12 AM, Harshavardhana <harsha@xxxxxxxxxxx> wrote:
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@xxxxxxxxxx> wrote:On Thu, Jul 16, 2009 at 08:24:09PM +0530, Harshavardhana wrote:ACK, I see why you need this for the current releases of kernel/glusterfs.
> Hi Daniel,
>
> On Thu, Jul 16, 2009 at 7:46 PM, Daniel P. Berrange <berrange@xxxxxxxxxx>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.
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/ :|
|: 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