On Tue, Dec 13, 2011 at 02:57:33PM -0500, Saggi Mizrahi wrote:
On Sun 11 Dec 2011 10:15:23 AM EST, Andrew Cathrow wrote:
----- Original Message -----
From: "Saggi Mizrahi"smizrahi@redhat.com To: "VDSM Project Development"vdsm-devel@lists.fedorahosted.org, engine-devel@ovirt.org Sent: Friday, December 9, 2011 5:41:42 PM Subject: [Engine-devel] shared fs support
Hi, I have preliminary (WIP) patches for shared FS up on gerrit. There is a lot of work to be done reorganizing the patches but I just wanted all the TLV guys to have a chance to look at it on Sunday.
I did some testing and should work as expected for most cases.
To test just connectStorageServer with storageType=6 (sharedfs) connection params are {'id'=1, 'spec'='server:/export' 'vfs_type'='nfs\gluster\smb' 'mnt_options'='opt,opt=3,opt' }
to check with an existing NFS domain you can just spec=server:/export vfs_type=nfs mnt_options=soft,timeo=600,retrans=6,nosharecache,vers=3
So does that mean that we treat nfs custom types differently -eg using the out or process stuff?
I only tested NFS but I am going to test more exotic stuff on Monday.
This is the patch to build the RPM from. http://gerrit.ovirt.org/#change,560
Have a good weekend
Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Using the custom NFS will give you the tested supported options and limits. Using sharedfs will give you a generic implementation. Currently the underlying implementation is the same. But there is a plan to use a simpler implementation (without using OOP as it's an NFS specific hack) and also loose stale handle checks and other NFS specific stuff.
Without a proof to the contraty, I would suspect that other shared file system would have the tendency to disappear, leaving client application in D state. We may need the oop hack for them, too.