----- 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 >

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.

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.