Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
>> umount -l /mnt/drbd7 [ fails ] >> root at cloud15:/home/cloud15# lsof | grep drbd [ rearranged/snipped for clarity ] >> drbd7_worker 7354 ... / >> drbd7_receiver 27005 ... / >> drbd7_asender 27174 ... / Take another look at that. The working dir for those things is / , not anything within drbd. Those processes are showing up in the lsof/grep output because their names have drbd in them, not because their cwd is in /mnt/drbd7 or they have files open under /mnt/drbd7 . From: "Phillips, Dan" <Dan.Phillips at tekelec.com> > [root at jamaica-a ~]# ps -aux | grep 14557 > Warning: bad syntax, perhaps a bogus '-'? It's "ps aux"; no - needed if you're using the BSD ps syntax. You could always do "ps -ef" :-) > So drbd0_worker, drbd0_receiver and drbd0_asender have files open. > After a failover, should these processes still have a device(s) held > open? On the secondary nodes of several DRBD active/passive clusters, I get similar output when I do "lsof | grep drbd". drbd*_worker , _receiver , and _asender are all visible--and no files on the DRBD device are actually open on the secondary node, for obvious reasons. I've had one weird thing happen with lsof not showing any open files in /mnt/drbd0 and the primary refusing to umount /dev/drbd0 and fail over nicely. That was because there was a bind mount from /mnt/drbd0/somewhere/ to /blah/somewhere/else/ . This didn't actually show up in lsof's output. So check the output of mount? Or "lsof | grep 147,7" , which should show all the things on the device with major 147 minor 7 (/dev/drbd7) that are open? Or blame it all on Xen doing silly things? -- Matt G / Dances With Crows The Crow202 Blog: http://crow202.org/wordpress/ There is no Darkness in Eternity/But only Light too dim for us to see