[Engine-devel] shared fs support

[Saggi Mizrahi]

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