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
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
----- Original Message -----
From: "Saggi Mizrahi" smizrahi@redhat.com To: "VDSM Project Development" vdsm-devel@lists.fedorahosted.org, engine-devel@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@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
On Sun 11 Dec 2011 10:15:23 AM EST, Andrew Cathrow wrote:
----- Original Message -----
From: "Saggi Mizrahi"smizrahi@redhat.com To: "VDSM Project Development"vdsm-devel@lists.fedorahosted.org, engine-devel@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@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.
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@redhat.com To: "VDSM Project Development"vdsm-devel@lists.fedorahosted.org, engine-devel@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@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.
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@redhat.com To: "VDSM Project Development"vdsm-devel@lists.fedorahosted.org, engine-devel@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@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
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@redhat.com To: "VDSM Project Development"vdsm-devel@lists.fedorahosted.org, engine-devel@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@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.
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@redhat.com To: "VDSM Project Development"vdsm-devel@lists.fedorahosted.org, engine-devel@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@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@lists.stg.fedorahosted.org
-
Andrew Cathrow -
Dan Kenigsberg -
smizrahi＠redhat.com