[Engine-devel] shared fs support

[Dan Kenigsberg]

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 at redhat.com>
> >>>>To: "VDSM Project Development"<vdsm-devel at lists.fedorahosted.org>, engine-devel at 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 at 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.