Hi Guys,
i have another question on pNFS. I looked at my Wireshark protocols, while i used the FILE-Layout, and i wondered why i have no LAYOUTCOMMIT/LAYOUTRETURN statements in my protocols.
I transfered one file to my storage server (NETAPP Simulator 8.1 C-Mode) and i only got a LAYOUTGET.
cat /proc/self/mountstats | grep LAYOUT says:
nfsv4: bm0=0xfafe8fff,bml=0x60fdfffe,acl=0x3,sessions,pnfs=LAYOUT_NFSV4_1_FILES
LAYOUTGET: 1 1 0 216 236 0 1 1
LAYOUTCOMMIT: 0 0 0 0 0 0 0 0
LAYOUTRETURN: 0 0 0 0 0 0 0 0
Is there any other way to verify that pnfs is used on client site?
Thanks in advance
Best Regards
Johannes
--
Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de
Thanks for your fast reply. I'll look deeper in it.
Best Regards
Johannes
--
NEU: FreePhone 3-fach-Flat mit kostenlosem Smartphone!
Jetzt informieren: http://mobile.1und1.de/?ac=OM.PW.PW003K20328T7073a
On Mon, Jun 25, 2012 at 10:43 AM, Johannes Schild <[email protected]> wrote:
> Hi Guys,
>
> i have another question on pNFS. I looked at my Wireshark protocols, while i used the FILE-Layout, and i wondered why i have no LAYOUTCOMMIT/LAYOUTRETURN statements in my protocols.
> I transfered one file to my storage server (NETAPP Simulator 8.1 C-Mode) and i only got a LAYOUTGET.
>
> cat /proc/self/mountstats | grep LAYOUT says:
> nfsv4: bm0=0xfafe8fff,bml=0x60fdfffe,acl=0x3,sessions,pnfs=LAYOUT_NFSV4_1_FILES
> ? ?LAYOUTGET: 1 1 0 216 236 0 1 1
> ?LAYOUTCOMMIT: 0 0 0 0 0 0 0 0
> ?LAYOUTRETURN: 0 0 0 0 0 0 0 0
>
>
> Is there any other way to verify that pnfs is used on client site?
>
>
> Thanks in advance
>
>
> Best Regards
>
> Johannes
>
>
>
> --
> Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
> belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to [email protected]
> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
about layoutcommit:
http://tools.ietf.org/rfcmarkup?doc=5661#section-13.7
about layoutreturn:
http://tools.ietf.org/rfcmarkup?doc=5661#section-12.5.5.1
--
Idan Kedar
Tonian
On Mon, 2012-06-25 at 09:43 +0200, Johannes Schild wrote:
> Hi Guys,
>
> i have another question on pNFS. I looked at my Wireshark protocols, while i used the FILE-Layout, and i wondered why i have no LAYOUTCOMMIT/LAYOUTRETURN statements in my protocols.
> I transfered one file to my storage server (NETAPP Simulator 8.1 C-Mode) and i only got a LAYOUTGET.
>
> cat /proc/self/mountstats | grep LAYOUT says:
> nfsv4: bm0=0xfafe8fff,bml=0x60fdfffe,acl=0x3,sessions,pnfs=LAYOUT_NFSV4_1_FILES
> LAYOUTGET: 1 1 0 216 236 0 1 1
> LAYOUTCOMMIT: 0 0 0 0 0 0 0 0
> LAYOUTRETURN: 0 0 0 0 0 0 0 0
A pNFS client should never send LAYOUTCOMMIT to a server that does FILE_SYNC writes.
The Linux pNFS client uses the 'forgetful client' model, so it will
never send LAYOUTRETURN on layout recalls either. The only case where we
send LAYOUTRETURN is when the file falls out of the inode cache.
> Is there any other way to verify that pnfs is used on client site?
The most direct way is to look for a TCP connection to the data server
using 'netstat -t'.
Cheers
Trond
Hi,
thanks for your answers.
But how do i find out, whether the server is using FILE_SYNC?
Is there any other mode like "FILE_ASYNC"?
And if the server is using FILE_SYNC, how does it get LAYOUTCOMMIT?
Thanks in advance
Johannes
-------- Original-Nachricht --------
> Datum: Mon, 25 Jun 2012 09:46:40 -0400
> Von: Trond Myklebust <[email protected]>
> An: Johannes Schild <[email protected]>
> CC: [email protected]
> Betreff: Re: LAYOUTCOMMIT/LAYOUTRETURN
> On Mon, 2012-06-25 at 09:43 +0200, Johannes Schild wrote:
> > Hi Guys,
> >
> > i have another question on pNFS. I looked at my Wireshark protocols,
> while i used the FILE-Layout, and i wondered why i have no
> LAYOUTCOMMIT/LAYOUTRETURN statements in my protocols.
> > I transfered one file to my storage server (NETAPP Simulator 8.1 C-Mode)
> and i only got a LAYOUTGET.
> >
> > cat /proc/self/mountstats | grep LAYOUT says:
> > nfsv4:
> bm0=0xfafe8fff,bml=0x60fdfffe,acl=0x3,sessions,pnfs=LAYOUT_NFSV4_1_FILES
> > LAYOUTGET: 1 1 0 216 236 0 1 1
> > LAYOUTCOMMIT: 0 0 0 0 0 0 0 0
> > LAYOUTRETURN: 0 0 0 0 0 0 0 0
>
> A pNFS client should never send LAYOUTCOMMIT to a server that does
> FILE_SYNC writes.
>
> The Linux pNFS client uses the 'forgetful client' model, so it will
> never send LAYOUTRETURN on layout recalls either. The only case where we
> send LAYOUTRETURN is when the file falls out of the inode cache.
>
>
> > Is there any other way to verify that pnfs is used on client site?
>
> The most direct way is to look for a TCP connection to the data server
> using 'netstat -t'.
>
> Cheers
> Trond
>
--
NEU: FreePhone 3-fach-Flat mit kostenlosem Smartphone!
Jetzt informieren: http://mobile.1und1.de/?ac=OM.PW.PW003K20328T7073a
T24gVHVlLCAyMDEyLTA2LTI2IGF0IDE0OjQzICswMjAwLCBKb2hhbm5lcyBTY2hpbGQgd3JvdGU6
DQo+IEhpLA0KPiANCj4gdGhhbmtzIGZvciB5b3VyIGFuc3dlcnMuDQo+IA0KPiBCdXQgaG93IGRv
IGkgZmluZCBvdXQsIHdoZXRoZXIgdGhlIHNlcnZlciBpcyB1c2luZyBGSUxFX1NZTkM/DQoNCllv
dSBzYWlkIHlvdSB3ZXJlIHVzaW5nIGEgTmV0QXBwIGZpbGVyLiBUaGV5IGhhdmUgYW4gTlZSQU0g
Y2FjaGUgd2hpY2gNCm1lYW5zIHRoZXkgd2lsbCBhbHdheXMgdXNlIEZJTEVfU1lOQyBtb2RlIGZv
ciB3cml0ZXMuDQoNCj4gSXMgdGhlcmUgYW55IG90aGVyIG1vZGUgbGlrZSAiRklMRV9BU1lOQyI/
DQoNClBsZWFzZSBzZWUgdGhlIE5GUyBzcGVjLiBUaGVyZSBhcmUgMyB3cml0ZSBtb2RlczogRklM
RV9TWU5DID09IChkYXRhDQorbWV0YWRhdGEgY29tbWl0dGVkIHRvIGRpc2spLCBEQVRBX1NZTkMg
PT0gKGRhdGEgKyBmaWxlIHNpemUgY29tbWl0dGVkDQp0byBkaXNrKSwgVU5TVEFCTEUgPT0gKGRh
dGErbWV0YWRhdGEgaXMgY2FjaGVkIG9uIHRoZSBzZXJ2ZXIpLg0KDQo+IEFuZCBpZiB0aGUgc2Vy
dmVyIGlzIHVzaW5nIEZJTEVfU1lOQywgaG93IGRvZXMgaXQgZ2V0IExBWU9VVENPTU1JVD8NCg0K
SXQgZG9lc24ndCBuZWVkIGl0LiBBbGwgbWV0YWRhdGEgaXMgYWxyZWFkeSBvbiBkaXNrLg0KDQo+
IFRoYW5rcyBpbiBhZHZhbmNlDQo+IA0KPiANCj4gSm9oYW5uZXMNCj4gDQo+IA0KPiAtLS0tLS0t
LSBPcmlnaW5hbC1OYWNocmljaHQgLS0tLS0tLS0NCj4gPiBEYXR1bTogTW9uLCAyNSBKdW4gMjAx
MiAwOTo0Njo0MCAtMDQwMA0KPiA+IFZvbjogVHJvbmQgTXlrbGVidXN0IDx0cm9uZC5teWtsZWJ1
c3RAZnlzLnVpby5ubz4NCj4gPiBBbjogSm9oYW5uZXMgU2NoaWxkIDxKU2NoaWxkQGdteC5kZT4N
Cj4gPiBDQzogbGludXgtbmZzQHZnZXIua2VybmVsLm9yZw0KPiA+IEJldHJlZmY6IFJlOiBMQVlP
VVRDT01NSVQvTEFZT1VUUkVUVVJODQo+IA0KPiA+IE9uIE1vbiwgMjAxMi0wNi0yNSBhdCAwOTo0
MyArMDIwMCwgSm9oYW5uZXMgU2NoaWxkIHdyb3RlOg0KPiA+ID4gSGkgR3V5cywNCj4gPiA+IA0K
PiA+ID4gaSBoYXZlIGFub3RoZXIgcXVlc3Rpb24gb24gcE5GUy4gSSBsb29rZWQgYXQgbXkgV2ly
ZXNoYXJrIHByb3RvY29scywNCj4gPiB3aGlsZSBpIHVzZWQgdGhlIEZJTEUtTGF5b3V0LCBhbmQg
aSB3b25kZXJlZCB3aHkgaSBoYXZlIG5vDQo+ID4gTEFZT1VUQ09NTUlUL0xBWU9VVFJFVFVSTiBz
dGF0ZW1lbnRzIGluIG15IHByb3RvY29scy4NCj4gPiA+IEkgdHJhbnNmZXJlZCBvbmUgZmlsZSB0
byBteSBzdG9yYWdlIHNlcnZlciAoTkVUQVBQIFNpbXVsYXRvciA4LjEgQy1Nb2RlKQ0KPiA+IGFu
ZCBpIG9ubHkgZ290IGEgTEFZT1VUR0VULg0KPiA+ID4gDQo+ID4gPiBjYXQgL3Byb2Mvc2VsZi9t
b3VudHN0YXRzIHwgZ3JlcCBMQVlPVVQgc2F5czoNCj4gPiA+IG5mc3Y0Og0KPiA+IGJtMD0weGZh
ZmU4ZmZmLGJtbD0weDYwZmRmZmZlLGFjbD0weDMsc2Vzc2lvbnMscG5mcz1MQVlPVVRfTkZTVjRf
MV9GSUxFUw0KPiA+ID4gICAgIExBWU9VVEdFVDogMSAxIDAgMjE2IDIzNiAwIDEgMQ0KPiA+ID4g
IExBWU9VVENPTU1JVDogMCAwIDAgMCAwIDAgMCAwDQo+ID4gPiAgTEFZT1VUUkVUVVJOOiAwIDAg
MCAwIDAgMCAwIDAgDQo+ID4gDQo+ID4gQSBwTkZTIGNsaWVudCBzaG91bGQgbmV2ZXIgc2VuZCBM
QVlPVVRDT01NSVQgdG8gYSBzZXJ2ZXIgdGhhdCBkb2VzDQo+ID4gRklMRV9TWU5DIHdyaXRlcy4N
Cj4gPiANCj4gPiBUaGUgTGludXggcE5GUyBjbGllbnQgdXNlcyB0aGUgJ2ZvcmdldGZ1bCBjbGll
bnQnIG1vZGVsLCBzbyBpdCB3aWxsDQo+ID4gbmV2ZXIgc2VuZCBMQVlPVVRSRVRVUk4gb24gbGF5
b3V0IHJlY2FsbHMgZWl0aGVyLiBUaGUgb25seSBjYXNlIHdoZXJlIHdlDQo+ID4gc2VuZCBMQVlP
VVRSRVRVUk4gaXMgd2hlbiB0aGUgZmlsZSBmYWxscyBvdXQgb2YgdGhlIGlub2RlIGNhY2hlLg0K
PiA+IA0KPiA+IA0KPiA+ID4gSXMgdGhlcmUgYW55IG90aGVyIHdheSB0byB2ZXJpZnkgdGhhdCBw
bmZzIGlzIHVzZWQgb24gY2xpZW50IHNpdGU/DQo+ID4gDQo+ID4gVGhlIG1vc3QgZGlyZWN0IHdh
eSBpcyB0byBsb29rIGZvciBhIFRDUCBjb25uZWN0aW9uIHRvIHRoZSBkYXRhIHNlcnZlcg0KPiA+
IHVzaW5nICduZXRzdGF0IC10Jy4NCj4gPiANCj4gPiBDaGVlcnMNCj4gPiAgIFRyb25kDQo+ID4g
DQo+IA0KDQotLSANClRyb25kIE15a2xlYnVzdA0KTGludXggTkZTIGNsaWVudCBtYWludGFpbmVy
DQoNCk5ldEFwcA0KVHJvbmQuTXlrbGVidXN0QG5ldGFwcC5jb20NCnd3dy5uZXRhcHAuY29tDQoN
Cg==