급 질문 (dmesg log)

[강계정]

몇몇 서버에서 다음과 같은 로그가 보입니다..

무슨 내용인지 궁금합니다,,,

WARNING: nfs3_getattr_otw: EOVERFLOW (result size=0x00000000,c0100000)



WARNING: nfs3_getattr_otw: EOVERFLOW (result size=0x00000000,c0100000)



WARNING: nfs3_getattr_otw: EOVERFLOW (result size=0x00000000,c0100000)



WARNING: nfs3_getattr_otw: EOVERFLOW (result size=0x00000005,00000200)



WARNING: nfs3_getattr_otw: EOVERFLOW (result size=0x00000002,80000200)



WARNING: nfs3_getattr_otw: EOVERFLOW (result size=0x00000005,00000200)



WARNING: nfs3_getattr_otw: EOVERFLOW (result size=0x00000002,80000200)





도움 부탁드립니다,...

[김병수]

itrc에 아래와 같은 내용이 있으니 참조하시기 바랍니다.



이것은 HP의 문제가 아니라고 합니다.



old verion에 의한 것이니 version를 upgrade하시기 바랍니다.



참고내용..



This is not an HP failure. The Windows NT client was running MS Services

for UNIX version 1.0A which is very old. The current version is 3.0.

Refer to these Microsoft websites for this product:



Windows Services for UNIX 3.0 120-day Eval



Microsoft's Windows Services for Unix



Most PC NFS server products have the capability of setting preferred

read/write sizes up to 65536 bytes per datagram. This is larger than

HP clients can handle.



In this case, the HP client had requested, via the mount command, a

read/write size of 1024 bytes. The server ideally should have used

these for the transfer and preferred sizes, but, in this case, it

ignored it and used a transfer of 65536 and a preferred of 0 bytes.



Here is the trace showing the NFS3 Reply's FSINFO procedure where

filesystem statistics were reported :



========================= IP Header (inbound -- ) ================

Source: 10.20.36.40(A) Dest: 130.185.50.45(B)

len: 192 ttl: 125 proto: 17 cksum: 0xc418 id:

0x95f2

flags: NONE tos: 0x0 hdrlen: 20 offset: 0x0 optlen: 0

----------------------------- UDP Header -------------------------------

sport: 2049 --> dport: 1021 data len: 164 chksum: 0xdc66

----------------------------- RPC Reply --------------------------------

trans id: 0x5265b Accepted verif type: 0 verif length: 0

---------------------------- NFS3 Reply -------------------------------

proc : FSINFO status : OK

file type: 2 mode : 00777 hard links: 23

uid : 0 gid : 65534 size : 4096

used : 4096 major #: 0 minor # : 0

inode # : 3392535 fsid : 0xcbd42c54

accessed : Tue Aug 13 07:18:45.828125

modified : Mon Aug 12 12:46:12.109375

changed : Mon Aug 12 12:46:12.109375



Read transfer sizes (in bytes)

max : 65536 preferred: 0 suggested multiple: 0

Write transfer sizes (in bytes)

max : 65536 preferred: 0 suggested multiple: 0



Directory read sizes (in bytes)

preferred: 8192 maxfile size: 0

time delta: {0, 0}

properties: LINK SYMLINK HOMOGENEOUS CAN_SET_TIME

=======================================================================



An NFSv2 mount request from the client using the same syntax (...

rsize=1024,wsize=1024) worked fine.



In this case, it appears that the MS Services for UNIX version 1.0A

does not support, or work well with, NFSv3 (FSINFO procedure) mount

requests from HP clients. This is not a failure of the client. The

main issue here is that, in response to HP's advisory read/write size

request of 1024, a size is returned that either exceeds what can be

handled (64k), or is "0" bytes. This results in the nfs3_getattr_otw

(NFSv3 get attributes over-the-wire) being overflowed (it's zero size).



"nfsstat -m" confirms a read/write size of 0 bytes. This is controlled

by the server. The client makes an advisory recommendation of

bytes and the server should reply with the following attributes:



rtmax max size READ supported by server

rtpref preferred size of READ request

rtmult suggested multiple of READ request

wtmax max size WRITE supported by server

wtpref preferred size of WRITE request

wtmult suggested multiple of WRITE request

dtpref

maxfilesize maximum size of files for svr filesys

time_delta

properties



The server returned values of "0" bytes for file read/write preferred

and multiples. Also returned was a maxfilesize allowed of "0" bytes.

The client does not make these recommendations; these are what the

server is returning in the proc: FSINFO.



NOTE: FSINFO is an NFSv3-only procedure.

NFSv2 does a proc: STATFS.



This is a vendor-specific implementation issue with what to do when a

server ignores a client's suggested read/write size and returns a value

that is unusable by the client. Does the client ignore this and send a

default value (and risk exceeding the server's capability) or does it

provide an error? HP takes the conservative choice and errors with

nfs3_getattr_otw: EOVERFLOW. Not all vendors may follow this same

strategy.



An HP variable, mi_maxfilesize, is set to a very large value and then

reset to the value returned from the server in the FSINFO. This NT

server returned "0" bytes.



The following solutions to this issue have been observed:



1. Reboot PC NFS-server to clear/reset the entire environment.



2. Drop max read/write size on server from 64k to 32k for NFSv3.



3. Upgrade to a current, supported version of the PC-based NFS

product.



4. Contact the vendor of PC NFS server software and ask why

they are returning "0" bytes for preferred read/write and

maxfilesize sizes. Also ask why is the server ignoring

the clients recommendation for read/write size.



To summarize, MS Services for UNIX version 1.0A does not support NFSv3

even though it will grant the MOUNT3 request. Upgrading the version

to a supported release (current release is 3.0) resolves the problem.

[서보인]

안녕하세요.. 서보인 입니다.



itrc에서 다음과 같은 문서를 찾았습니다. 참고하세요..



PROBLEM

When an HP 11.00 NFS client mounts a NFS version 3 filesystem from a

Windows NT NFS server, the HP client reports in dmesg:



WARNING: nfs3_getattr_otw: EOVERFLOW (result size=0x00000000,

00001000)



"nfsstat -m" shows that both the read and write size are 0:



vers=3,proto=udp,auth=unix,hard,intr,link,symlink,devs,rsize=0,

wsize=0,retrans=5

Lookups: srtt= 46 (115ms), dev= 5 ( 25ms), cur= 8 (160ms)

All: srtt= 46 (115ms), dev= 5 ( 25ms), cur= 8 (160ms)



Why is this happening ?



CONFIGURATION

Operating System - HP-UX

Version - 11.0

Subsystem - NFS

RESOLUTION

This is not an HP failure. The Windows NT client was running MS Services for UNIX version 1.0A which is very old.

The current version is 3.0.

Refer to these Microsoft websites for this product:



Windows Services for UNIX 3.0 120-day Eval



Microsoft's Windows Services for Unix



Most PC NFS server products have the capability of setting preferred read/write sizes up to 65536 bytes per datagram. This is larger than HP clients can handle.



In this case, the HP client had requested, via the mount command, a read/write size of 1024 bytes. The server ideally should have used these for the transfer and preferred sizes,

but, in this case, it ignored it and used a transfer of 65536 and a preferred of 0 bytes.



Here is the trace showing the NFS3 Reply's FSINFO procedure where

filesystem statistics were reported :



========================= IP Header (inbound -- ) ================

Source: 10.20.36.40(A) Dest: 130.185.50.45(B)

len: 192 ttl: 125 proto: 17 cksum: 0xc418 id:

0x95f2

flags: NONE tos: 0x0 hdrlen: 20 offset: 0x0 optlen: 0

----------------------------- UDP Header -------------------------------

sport: 2049 --> dport: 1021 data len: 164 chksum: 0xdc66

----------------------------- RPC Reply --------------------------------

trans id: 0x5265b Accepted verif type: 0 verif length: 0

---------------------------- NFS3 Reply -------------------------------

proc : FSINFO status : OK

file type: 2 mode : 00777 hard links: 23

uid : 0 gid : 65534 size : 4096

used : 4096 major #: 0 minor # : 0

inode # : 3392535 fsid : 0xcbd42c54

accessed : Tue Aug 13 07:18:45.828125

modified : Mon Aug 12 12:46:12.109375

changed : Mon Aug 12 12:46:12.109375



Read transfer sizes (in bytes)

max : 65536 preferred: 0 suggested multiple: 0

Write transfer sizes (in bytes)

max : 65536 preferred: 0 suggested multiple: 0



Directory read sizes (in bytes)

preferred: 8192 maxfile size: 0

time delta: {0, 0}

properties: LINK SYMLINK HOMOGENEOUS CAN_SET_TIME

=======================================================================



An NFSv2 mount request from the client using the same syntax (...

rsize=1024,wsize=1024) worked fine.



In this case, it appears that the MS Services for UNIX version 1.0A does not support, or work well with,

NFSv3 (FSINFO procedure) mount requests from HP clients. This is not a failure of the client.

The main issue here is that, in response to HP's advisory read/write size request of 1024, a size is returned that either exceeds what can be handled (64k), or is "0" bytes. This results in the nfs3_getattr_otw (NFSv3 get attributes over-the-wire) being overflowed (it's zero size).



"nfsstat -m" confirms a read/write size of 0 bytes. This is controlled by the server. The client makes an advisory recommendation of bytes and the server should reply with the following attributes:



rtmax max size READ supported by server

rtpref preferred size of READ request

rtmult suggested multiple of READ request

wtmax max size WRITE supported by server

wtpref preferred size of WRITE request

wtmult suggested multiple of WRITE request

dtpref

maxfilesize maximum size of files for svr filesys

time_delta

properties



The server returned values of "0" bytes for file read/write preferred and multiples. Also returned was a maxfilesize allowed of "0" bytes.

The client does not make these recommendations; these are what the

server is returning in the proc: FSINFO.



NOTE: FSINFO is an NFSv3-only procedure.

NFSv2 does a proc: STATFS.



This is a vendor-specific implementation issue with what to do when a server ignores a client's suggested read/write size and returns a value that is unusable by the client. Does the client ignore this and send a default value (and risk exceeding the server's capability) or does it provide an error? HP takes the conservative choice and errors with nfs3_getattr_otw: EOVERFLOW. Not all vendors may follow this same strategy.



An HP variable, mi_maxfilesize, is set to a very large value and then reset to the value returned from the server in the FSINFO. This NT server returned "0" bytes.



The following solutions to this issue have been observed:



1. Reboot PC NFS-server to clear/reset the entire environment.



2. Drop max read/write size on server from 64k to 32k for NFSv3.



3. Upgrade to a current, supported version of the PC-based NFS

product.



4. Contact the vendor of PC NFS server software and ask why

they are returning "0" bytes for preferred read/write and

maxfilesize sizes. Also ask why is the server ignoring

the clients recommendation for read/write size.



To summarize, MS Services for UNIX version 1.0A does not support NFSv3 even though it will grant the MOUNT3 request. Upgrading the version to a supported release (current release is 3.0) resolves the problem.



ALT KEYWORDS

nfs3_getattr_otw

"nfs3_getattr_otw: EOVERFLOW"

eoverflow

fsinfo



http://www1.itrc.hp.com/service/cki/docDisplay.do?docLocale=en_US&docId=200000080023724



Good luck!!