Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

I have a disk in a server that I'm migrating to a LVM volume group. Previously, it was using traditional DOS-disk partitioning, hdb[1-5].

I've unmounted every filesystem from hdb, shut off swap using hdb, removed a smaller VG on the device already, and went to repartition it using fdisk, deleted existing partitions, and created 2 partitions, but upon writing it out, linux refused to re-read the partition table. Trying again using hdparm -z reports: BLKRRPART failed: Device or resource busy.

I've checked the following places to ensure the device and it's partitions arn't listed anywhere:

  • /proc/swaps
  • /proc/mdadm
  • output from 'pvs' command
  • output from 'mount' command
  • /etc/mtab
  • lsof | grep hdb

But cat /proc/partitions still lists the partitioning, and hdparm -z /dev/hdb still gives me device busy.

Is there a something I'm missing, or a secret place I don't yet know about to find what's still holding on to my block device? and more importantly, How can I release it's hold so I can reload the partition table?

FWIW, on this specific case, I can simply reboot the server w/o much worry, but this has plagued me before, and I'm curious if there is a better way.

(Edit: added more precise wording) (Edit: details re repartitioning)

Update: I used partprobe /dev/hdb, and it did change things: in /dev /hdb1, /deb/hdb[3-5] are now gone, and partprobe is reporting Error: Error informing the kernel about modifications to partition /dev/hdb1 -- Device or resource busy. <-- specifically about hdb1. hdb1 formerly was a Physical Volume (PV) in a LVM Volume Group (VG), abut i vgremove + pvremoved em before I repartitioned......

Update 2: FWIW, I still haven't corrected this problem, fortunatly it's not urgent. I've learned that partprobe is using a newer API call which is why it did seem to do something earlier. I still haven't found an simple and effective way to, given a device, and it's major/minor numbers, figure out which resources (kernel or userspace) are using it. Any ideas?

share|improve this question
    
Check again with pvdisplay and vgdisplay if this partition is still assigned to any LVM –  Sunny Mar 5 '10 at 17:14

4 Answers 4

up vote 3 down vote accepted

Try using fuser

fuser -vam /dev/hdb1
share|improve this answer
    
I tried fuser on /dev/hdb and /dev/hdb[1-5], and it's still reporting nothing using those devices. –  Jason Mar 4 '10 at 21:50
    
FWIW, I never fully resolved this, but I've since restarted the machine, and that corrected it. Thanks for your help! –  Jason May 24 '10 at 13:36

lsof is the command you're looking for. You'll normally want to pipe it to grep with the mount point.

Example lsof | grep var will list all processes that have open files where the path or filename contains "var"

share|improve this answer
    
disregard my answer...I see that you did lsof at the bottom of your list....missed that when I answered the question. –  3dinfluence Mar 4 '10 at 19:46

What is the output of the command mount. Not sure if this applies to your situation, but I know I have used bind mounts on several occasions. Un-mounting the source filesystem from a bind-mount does not unmount bind mounts. The output of mount isn't very useful in this case for letting you know what is going on.

share|improve this answer
    
mount | grep hdb doesn't list anything; mount | grep /oldmountpoint doesn't doesn't list anything under the old mount point, and only shows the new device @ the old mount point, that I had moved stuff to. I was able to completely unmount it before the repartition, which indicates (to me at least) that there was nothing binding under it, and it wasn't bound elsewhere. –  Jason Mar 4 '10 at 21:00

Eddy's fuser -vam /dev/hdb1 example was essentially correct, but it lacked some completeness. In my case, I ran into a similar problem while recovering files from someone off the last drive of a raid1 array where the partition holding the data was in LVM.

In this case, I had started photorec to examine the drive, seen that there was a volume group, and then closed the terminal running photorec. Unbeknownst to me, photorec was still holding on to /dev/mapper/vg0-lv0. So, in the future, try using fuser, but on the contents of /dev/mapper/

fuser -vam /dev/mapper/*

This still probably not the best answer, but remember to try to check against any files under /dev/ that might also map in some way to the block device you're trying to use.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.