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"<firstname.lastname@example.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
I did some testing and should work as expected for most cases.
To test just connectStorageServer with storageType=6 (sharedfs)
connection params are
to check with an existing NFS domain you can just
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.
Have a good weekend
Engine-devel mailing list
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
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.
vdsm-devel mailing list