[Engine-devel] shared fs support

[Saggi Mizrahi]

On Fri 16 Dec 2011 06:22:59 AM EST, Dan Kenigsberg wrote:
> 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.
support is come complain on the mailing list if something doesn't work
if you want your storage to work write a domain for it. We are not 
going to add every hack in the universe to 1 domain.
>
> 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.