[pve-devel] [PATCH] migrate: syncdisk : avoid scanning shared storage

[Alexandre DERUMIER]

Thanks for the infos,

so, for get timeout, we need to use "soft" mount option

but
" A so-called "soft" timeout can cause silent data corruption in certain cases."

:/

Maybe pinging the nfs server, before sending command (ls,rm,...) is the best way to avoid proxmox hang ?




----- Mail original ----- 

De: "datanom.net" <mir at datanom.net> 
À: pve-devel at pve.proxmox.com 
Envoyé: Lundi 16 Juillet 2012 16:15:51 
Objet: Re: [pve-devel] [PATCH] migrate: syncdisk : avoid scanning shared storage 

On 07-16-2012 15:19, Alexandre DERUMIER wrote: 
> Seem strange that user report hang, as nfs default timeout is 0.7 
> second according the doc. 
> 
The picture is more muddy than alone looking at the NFS doc. If a NFS 
share disappears 
while writing to the share and nfslock is active then nfslock on the 
client and nfsd 
on the server will leave dangling file locks hanging. If this is 
combined with the 
mount option hard then the service will be lock until nfsd is restartet 
on the server. 

>From the client perspective this situation will be seen as a socket 
which hangs forever 
and never do timeout. 

Some interesting mount options which have a huge impact on NFS and NFS 
behavior: 

soft / hard Determines the recovery behavior of the NFS 
client after 
an NFS request times out. If neither option is 
speci‐ 
fied (or if the hard option is specified), NFS 
requests 
are retried indefinitely. If the soft option is 
speci‐ 
fied, then the NFS client fails an NFS 
request after 
retrans retransmissions have been sent, causing 
the NFS 
client to return an error to the calling 
application. 

NB: A so-called "soft" timeout can cause 
silent data 
corruption in certain cases. As such, use 
the soft 
option only when client responsiveness is more 
important 
than data integrity. Using NFS over TCP or 
increasing 
the value of the retrans option may mitigate some 
of the 
risks of using the soft option. 

lock / nolock Selects whether to use the NLM sideband protocol 
to lock 
files on the server. If neither option is 
specified (or 
if lock is specified), NLM locking is used 
for this 
mount point. When using the nolock option, 
applications 
can lock files, but such locks provide 
exclusion only 
against other applications running on the same 
client. 
Remote applications are not affected by these 
locks. 

NLM locking must be disabled with the nolock 
option when 
using NFS to mount /var because /var contains 
files used 
by the NLM implementation on Linux. Using the 
nolock 
option is also required when mounting exports 
on NFS 
servers that do not support the NLM protocol. 

intr / nointr Selects whether to allow signals to interrupt 
file oper‐ 
ations on this mount point. If neither option is 
speci‐ 
fied (or if nointr is specified), signals do not 
inter‐ 
rupt NFS file operations. If intr is specified, 
system 
calls return EINTR if an in-progress NFS 
operation is 
interrupted by a signal. 

Using the intr option is preferred to using 
the soft 
option because it is significantly less likely to 
result 

in data corruption. 

The intr / nointr mount option is deprecated 
after ker‐ 
nel 2.6.25. Only SIGKILL can interrupt a 
pending NFS 
operation on these kernels, and if specified, 
this mount 
option is ignored to provide backwards 
compatibility 
with older kernels. 

_______________________________________________ 
pve-devel mailing list 
pve-devel at pve.proxmox.com 
http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel 



-- 

-- 



	

Alexandre D e rumier 

Ingénieur Systèmes et Réseaux 


Fixe : 03 20 68 88 85 

Fax : 03 20 68 90 88 


45 Bvd du Général Leclerc 59100 Roubaix 
12 rue Marivaux 75002 Paris