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


_______________________________________________
vdsm-devel mailing list
vdsm-devel@lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/vdsm-devel

Reply via email to