[DRBD-user] Identifying High iowait on DRBD Computers

Robinson, Eric eric.robinson at psmnv.com
Thu Feb 17 22:36:57 CET 2011

Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.


Matt,

> > This is an older Heartbeat haresources-based cluster. Would your 
> > suggestion work even when kill -9 won't kill the nfs, nfsd, or
> > mfsd4 processes? They simply would not die. I suspect this 
> is because 
> > they are in use by another process.
> 
> If so, then kill *that* process.  lsof and/or fuser can help 
> a lot with determining what's using things and killing those things.
> 

Couldn't it be someone sitting in the mounted directory on an NFS client
computer? Getting to that might be hard. Is there some way to get a hung
nfsd to quit waiting for whatever it is waiting for?

> 
> Under Linux, a process in state D (waiting for a syscall to 
> return) *cannot* be killed, even with SIGKILL.  The kernel 
> programmers found a number of circumstances where terminating 
> a process in state D could lead to Undefined Behavior, as I 
> understand it.  The example I remember was a process doing a
> read() syscall on a dodgy disk.  Kernel code says, "When the 
> read from the disk completes, I'll use DMA to shove the 
> result into page 0x131072."  Disk can't deliver immediately 
> because it's flaky.  User kill -9s the process. 
> Kernel MM code releases page 0x131072, some other process 
> grabs hold of that page.  Disk eventually gets its act 
> together, uses DMA to write data to that page, other process 
> gets its data corrupted.  How embarrassing.
> 

Thanks for the explanation. I figured it was something like that. It's
way too frustrating a problem for someone not to have fixed it
otherwise.

--Eric







Disclaimer - February 17, 2011 
This email and any files transmitted with it are confidential and intended solely for Matt Graham,drbd-user at lists.linbit.com. If you are not the named addressee you should not disseminate, distribute, copy or alter this email. Any views or opinions presented in this email are solely those of the author and might not represent those of Physicians' Managed Care or Physician Select Management. Warning: Although Physicians' Managed Care or Physician Select Management has taken reasonable precautions to ensure no viruses are present in this email, the company cannot accept responsibility for any loss or damage arising from the use of this email or attachments. 
This disclaimer was added by Policy Patrol: http://www.policypatrol.com/



More information about the drbd-user mailing list