Re: [Engine-devel] shared fs support

On Thu, Dec 15, 2011 at 12:37:58PM -0500, Saggi Mizrahi wrote: > On Wed 14 Dec 2011 02:29:53 AM EST, Dan Kenigsberg wrote: >> 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(a)redhat.com> >>>>> To: "VDSM Project Development"<vdsm-devel(a)lists.fedorahosted.org>, engine-devel(a)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(a)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. >> > > They are unsupported, if we find a solution for the NFS issue then I > want to tear all the oop code down, not leave it because other > random NAS suffers from the same problems "support"? what's that? We are in upstream now.

If we have the code, and it is proved to help a random NAS user, we should not tear it down. We should factor it away, make it easily disable-able, and let its theoretical users maintain it. Dan.