From smizrahi at redhat.com Fri Dec 9 17:41:44 2011 Content-Type: multipart/mixed; boundary="===============4441724271914953611==" MIME-Version: 1.0 From: Saggi Mizrahi To: devel at ovirt.org Subject: [Engine-devel] shared fs support Date: Fri, 09 Dec 2011 17:41:42 -0500 Message-ID: <4EE28EA6.2050906@redhat.com> --===============4441724271914953611== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable This is a multi-part message in MIME format. --------------050004010107020802030308 Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed Content-Transfer-Encoding: 7bit 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=3D6 (sharedfs) connection params are {'id'=3D1, 'spec'=3D'server:/export' 'vfs_type'=3D'nfs\gluster\smb' 'mnt_options'=3D'opt,opt=3D3,opt' } to check with an existing NFS domain you can just spec=3Dserver:/export vfs_type=3Dnfs mnt_options=3Dsoft,timeo=3D600,retrans=3D6,nosharecache,vers=3D3 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 --------------050004010107020802030308 Content-Type: text/html; charset=3DISO-8859-1 Content-Transfer-Encoding: 7bit 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=3D6 (sharedfs)
connection params are
{'id'=3D1,
  'spec'=3D'server:/export'
  'vfs_type'=3D'nfs\gluster\smb'
  'mnt_options'=3D'opt,opt=3D3,opt' }

to check with an existing NFS domain you can just
spec=3Dserver:/export
vfs_type=3Dnfs
mnt_options=3Dsoft,timeo=3D600,retrans=3D6,nosharecache,vers=3D3

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
--------------050004010107020802030308-- --===============4441724271914953611== Content-Type: multipart/alternative MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="attachment.bin" VGhpcyBpcyBhIG11bHRpLXBhcnQgbWVzc2FnZSBpbiBNSU1FIGZvcm1hdC4KLS0tLS0tLS0tLS0t LS0wNTAwMDQwMTAxMDcwMjA4MDIwMzAzMDgKQ29udGVudC1UeXBlOiB0ZXh0L3BsYWluOyBjaGFy c2V0PUlTTy04ODU5LTE7IGZvcm1hdD1mbG93ZWQKQ29udGVudC1UcmFuc2Zlci1FbmNvZGluZzog N2JpdAoKSGksIEkgaGF2ZSBwcmVsaW1pbmFyeSAoV0lQKSBwYXRjaGVzIGZvciBzaGFyZWQgRlMg dXAgb24gZ2Vycml0LiBUaGVyZSAKaXMgYSBsb3Qgb2Ygd29yayB0byBiZSBkb25lIHJlb3JnYW5p emluZyB0aGUgcGF0Y2hlcyBidXQgSSBqdXN0IHdhbnRlZCAKYWxsIHRoZSBUTFYgZ3V5cyB0byBo YXZlIGEgY2hhbmNlIHRvIGxvb2sgYXQgaXQgb24gU3VuZGF5LgoKSSBkaWQgc29tZSB0ZXN0aW5n IGFuZCBzaG91bGQgd29yayBhcyBleHBlY3RlZCBmb3IgbW9zdCBjYXNlcy4KClRvIHRlc3QganVz dCBjb25uZWN0U3RvcmFnZVNlcnZlciB3aXRoIHN0b3JhZ2VUeXBlPTYgKHNoYXJlZGZzKQpjb25u ZWN0aW9uIHBhcmFtcyBhcmUKeydpZCc9MSwKICAgJ3NwZWMnPSdzZXJ2ZXI6L2V4cG9ydCcKICAg J3Zmc190eXBlJz0nbmZzXGdsdXN0ZXJcc21iJwogICAnbW50X29wdGlvbnMnPSdvcHQsb3B0PTMs b3B0JyB9Cgp0byBjaGVjayB3aXRoIGFuIGV4aXN0aW5nIE5GUyBkb21haW4geW91IGNhbiBqdXN0 CnNwZWM9c2VydmVyOi9leHBvcnQKdmZzX3R5cGU9bmZzCm1udF9vcHRpb25zPXNvZnQsdGltZW89 NjAwLHJldHJhbnM9Nixub3NoYXJlY2FjaGUsdmVycz0zCgpJIG9ubHkgdGVzdGVkIE5GUyBidXQg SSBhbSBnb2luZyB0byB0ZXN0IG1vcmUgZXhvdGljIHN0dWZmIG9uIE1vbmRheS4KClRoaXMgaXMg dGhlIHBhdGNoIHRvIGJ1aWxkIHRoZSBSUE0gZnJvbS4KaHR0cDovL2dlcnJpdC5vdmlydC5vcmcv I2NoYW5nZSw1NjAKCkhhdmUgYSBnb29kIHdlZWtlbmQKCi0tLS0tLS0tLS0tLS0tMDUwMDA0MDEw MTA3MDIwODAyMDMwMzA4CkNvbnRlbnQtVHlwZTogdGV4dC9odG1sOyBjaGFyc2V0PUlTTy04ODU5 LTEKQ29udGVudC1UcmFuc2Zlci1FbmNvZGluZzogN2JpdAoKPGh0bWw+CiAgPGhlYWQ+CgogICAg PG1ldGEgaHR0cC1lcXVpdj0iY29udGVudC10eXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJz ZXQ9SVNPLTg4NTktMSI+CiAgPC9oZWFkPgogIDxib2R5IHRleHQ9IiMwMDAwMDAiIGJnY29sb3I9 IiNGRkZGRkYiPgogICAgPGZvbnQgc2l6ZT0iLTEiPkhpLCBJIGhhdmUgcHJlbGltaW5hcnkgKFdJ UCkgcGF0Y2hlcyBmb3Igc2hhcmVkIEZTCiAgICAgIHVwIG9uIGdlcnJpdC4gVGhlcmUgaXMgYSBs b3Qgb2Ygd29yayB0byBiZSBkb25lIHJlb3JnYW5pemluZyB0aGUKICAgICAgcGF0Y2hlcyBidXQg SSBqdXN0IHdhbnRlZCBhbGwgdGhlIFRMViBndXlzIHRvIGhhdmUgYSBjaGFuY2UgdG8KICAgICAg bG9vayBhdCBpdCBvbiBTdW5kYXkuPGJyPgogICAgICA8YnI+CiAgICAgIEkgZGlkIHNvbWUgdGVz dGluZyBhbmQgc2hvdWxkIHdvcmsgYXMgZXhwZWN0ZWQgZm9yIG1vc3QgY2FzZXMuPGJyPgogICAg ICA8YnI+CiAgICAgIFRvIHRlc3QganVzdCBjb25uZWN0U3RvcmFnZVNlcnZlciB3aXRoIHN0b3Jh Z2VUeXBlPTYgKHNoYXJlZGZzKTxicj4KICAgICAgY29ubmVjdGlvbiBwYXJhbXMgYXJlPGJyPgog ICAgICB7J2lkJz0xLDxicj4KICAgICAgJm5ic3A7ICdzcGVjJz0nc2VydmVyOi9leHBvcnQnPGJy PgogICAgICAmbmJzcDsgJ3Zmc190eXBlJz0nbmZzXGdsdXN0ZXJcc21iJzxicj4KICAgICAgJm5i c3A7ICdtbnRfb3B0aW9ucyc9J29wdCxvcHQ9MyxvcHQnIH08YnI+CiAgICAgIDxicj4KICAgICAg dG8gY2hlY2sgd2l0aCBhbiBleGlzdGluZyBORlMgZG9tYWluIHlvdSBjYW4ganVzdDxicj4KICAg ICAgc3BlYz1zZXJ2ZXI6L2V4cG9ydDxicj4KICAgICAgdmZzX3R5cGU9bmZzPGJyPgogICAgICBt bnRfb3B0aW9ucz1zb2Z0LHRpbWVvPTYwMCxyZXRyYW5zPTYsbm9zaGFyZWNhY2hlLHZlcnM9Mzxi cj4KICAgICAgPGJyPgogICAgICBJIG9ubHkgdGVzdGVkIE5GUyBidXQgSSBhbSBnb2luZyB0byB0 ZXN0IG1vcmUgZXhvdGljIHN0dWZmIG9uCiAgICAgIE1vbmRheS48YnI+CiAgICAgIDxicj4KICAg ICAgVGhpcyBpcyB0aGUgcGF0Y2ggdG8gYnVpbGQgdGhlIFJQTSBmcm9tLjxicj4KICAgIDwvZm9u dD4KICAgIDxtZXRhIGh0dHAtZXF1aXY9ImNvbnRlbnQtdHlwZSIgY29udGVudD0idGV4dC9odG1s OwogICAgICBjaGFyc2V0PUlTTy04ODU5LTEiPgogICAgPGEgaHJlZj0iaHR0cDovL2dlcnJpdC5v dmlydC5vcmcvI2NoYW5nZSw1NjAiPmh0dHA6Ly9nZXJyaXQub3ZpcnQub3JnLyNjaGFuZ2UsNTYw PC9hPjxicj4KICAgIDxicj4KICAgIEhhdmUgYSBnb29kIHdlZWtlbmQ8YnI+CiAgPC9ib2R5Pgo8 L2h0bWw+CgotLS0tLS0tLS0tLS0tLTA1MDAwNDAxMDEwNzAyMDgwMjAzMDMwOC0tCg== --===============4441724271914953611==-- From acathrow at redhat.com Sun Dec 11 10:15:25 2011 Content-Type: multipart/mixed; boundary="===============1037457212390732323==" MIME-Version: 1.0 From: Andrew Cathrow To: devel at ovirt.org Subject: Re: [Engine-devel] shared fs support Date: Sun, 11 Dec 2011 10:15:23 -0500 Message-ID: In-Reply-To: 4EE28EA6.2050906@redhat.com --===============1037457212390732323== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable ----- Original Message ----- > From: "Saggi Mizrahi" > To: "VDSM Project Development" , eng= ine-devel(a)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=3D6 (sharedfs) > connection params are > {'id'=3D1, > 'spec'=3D'server:/export' > 'vfs_type'=3D'nfs\gluster\smb' > 'mnt_options'=3D'opt,opt=3D3,opt' } > = > to check with an existing NFS domain you can just > spec=3Dserver:/export > vfs_type=3Dnfs > mnt_options=3Dsoft,timeo=3D600,retrans=3D6,nosharecache,vers=3D3 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(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel >=20 --===============1037457212390732323==-- From smizrahi at redhat.com Tue Dec 13 14:57:37 2011 Content-Type: multipart/mixed; boundary="===============1535830950530716543==" MIME-Version: 1.0 From: Saggi Mizrahi To: devel at ovirt.org Subject: Re: [Engine-devel] shared fs support Date: Tue, 13 Dec 2011 14:57:33 -0500 Message-ID: <4EE7AE2D.8040206@redhat.com> In-Reply-To: ce9d4017-f8ab-4305-a604-48ca5dd8e0b7@zmail07.collab.prod.int.phx2.redhat.com --===============1535830950530716543== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On Sun 11 Dec 2011 10:15:23 AM EST, Andrew Cathrow wrote: > > > ----- Original Message ----- >> From: "Saggi Mizrahi" >> To: "VDSM Project Development", eng= ine-devel(a)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=3D6 (sharedfs) >> connection params are >> {'id'=3D1, >> 'spec'=3D'server:/export' >> 'vfs_type'=3D'nfs\gluster\smb' >> 'mnt_options'=3D'opt,opt=3D3,opt' } >> >> to check with an existing NFS domain you can just >> spec=3Dserver:/export >> vfs_type=3Dnfs >> mnt_options=3Dsoft,timeo=3D600,retrans=3D6,nosharecache,vers=3D3 > > So does that mean that we treat nfs custom types differently -eg using t= he 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(a)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. --===============1535830950530716543==-- From danken at redhat.com Wed Dec 14 02:29:58 2011 Content-Type: multipart/mixed; boundary="===============7308191104215653390==" MIME-Version: 1.0 From: Dan Kenigsberg To: devel at ovirt.org Subject: Re: [Engine-devel] shared fs support Date: Wed, 14 Dec 2011 09:29:53 +0200 Message-ID: <20111214072952.GA4173@redhat.com> In-Reply-To: 4EE7AE2D.8040206@redhat.com --===============7308191104215653390== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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" > >> To: "VDSM Project Development", e= ngine-devel(a)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=3D6 (sharedfs) > >> connection params are > >> {'id'=3D1, > >> 'spec'=3D'server:/export' > >> 'vfs_type'=3D'nfs\gluster\smb' > >> 'mnt_options'=3D'opt,opt=3D3,opt' } > >> > >> to check with an existing NFS domain you can just > >> spec=3Dserver:/export > >> vfs_type=3Dnfs > >> mnt_options=3Dsoft,timeo=3D600,retrans=3D6,nosharecache,vers=3D3 > > > > 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(a)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. --===============7308191104215653390==-- From smizrahi at redhat.com Thu Dec 15 12:38:22 2011 Content-Type: multipart/mixed; boundary="===============5683155391796978364==" MIME-Version: 1.0 From: Saggi Mizrahi To: devel at ovirt.org Subject: Re: [Engine-devel] shared fs support Date: Thu, 15 Dec 2011 12:37:58 -0500 Message-ID: <4EEA3076.7020304@redhat.com> In-Reply-To: 20111214072952.GA4173@redhat.com --===============5683155391796978364== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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" >>>> To: "VDSM Project Development", e= ngine-devel(a)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=3D6 (sharedfs) >>>> connection params are >>>> {'id'=3D1, >>>> 'spec'=3D'server:/export' >>>> 'vfs_type'=3D'nfs\gluster\smb' >>>> 'mnt_options'=3D'opt,opt=3D3,opt' } >>>> >>>> to check with an existing NFS domain you can just >>>> spec=3Dserver:/export >>>> vfs_type=3Dnfs >>>> mnt_options=3Dsoft,timeo=3D600,retrans=3D6,nosharecache,vers=3D3 >>> >>> 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(a)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 --===============5683155391796978364==-- From danken at redhat.com Fri Dec 16 06:23:03 2011 Content-Type: multipart/mixed; boundary="===============7268626807922841795==" MIME-Version: 1.0 From: Dan Kenigsberg To: devel at ovirt.org Subject: Re: [Engine-devel] shared fs support Date: Fri, 16 Dec 2011 13:22:59 +0200 Message-ID: <20111216112258.GB23503@redhat.com> In-Reply-To: 4EEA3076.7020304@redhat.com --===============7268626807922841795== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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" > >>>>To: "VDSM Project Development", = engine-devel(a)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=3D6 (sharedfs) > >>>>connection params are > >>>>{'id'=3D1, > >>>>'spec'=3D'server:/export' > >>>>'vfs_type'=3D'nfs\gluster\smb' > >>>>'mnt_options'=3D'opt,opt=3D3,opt' } > >>>> > >>>>to check with an existing NFS domain you can just > >>>>spec=3Dserver:/export > >>>>vfs_type=3Dnfs > >>>>mnt_options=3Dsoft,timeo=3D600,retrans=3D6,nosharecache,vers=3D3 > >>> > >>>So does that mean that we treat nfs custom types differently -eg usin= g 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(a)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 le= t its theoretical users maintain it. Dan. --===============7268626807922841795==-- From smizrahi at redhat.com Fri Dec 16 10:31:53 2011 Content-Type: multipart/mixed; boundary="===============8059076619398859324==" MIME-Version: 1.0 From: Saggi Mizrahi To: devel at ovirt.org Subject: Re: [Engine-devel] shared fs support Date: Fri, 16 Dec 2011 10:31:51 -0500 Message-ID: <4EEB6467.7080300@redhat.com> In-Reply-To: 20111216112258.GB23503@redhat.com --===============8059076619398859324== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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" >>>>>> To: "VDSM Project Development",= engine-devel(a)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=3D6 (sharedfs) >>>>>> connection params are >>>>>> {'id'=3D1, >>>>>> 'spec'=3D'server:/export' >>>>>> 'vfs_type'=3D'nfs\gluster\smb' >>>>>> 'mnt_options'=3D'opt,opt=3D3,opt' } >>>>>> >>>>>> to check with an existing NFS domain you can just >>>>>> spec=3Dserver:/export >>>>>> vfs_type=3Dnfs >>>>>> mnt_options=3Dsoft,timeo=3D600,retrans=3D6,nosharecache,vers=3D3 >>>>> >>>>> So does that mean that we treat nfs custom types differently -eg usi= ng 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(a)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 shoul= d not > tear it down. We should factor it away, make it easily disable-able, and = let its > theoretical users maintain it. > > Dan. --===============8059076619398859324==--