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?
Try using fuser
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 runningphotorec
. Unbeknownst to me,photorec
was still holding on to/dev/mapper/vg0-lv0
. So, in the future, try usingfuser
, 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.
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"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.