refresh partition table

Harald Becker ralda at gmx.de
Mon May 16 16:29:12 UTC 2011


 Hallo David!

On 16.05.2011 18:05, David Henderson wrote:
> On 05/16/2011 11:20 AM, David Henderson wrote:
>> On 05/16/2011 11:09 AM, David Henderson wrote:
>>> On 05/16/2011 10:52 AM, David Henderson wrote:
>>>> On 05/15/2011 04:27 PM, Sergey Naumov wrote:
>>>>> blockdev --rereadpt
>>>>>
>>>>> Sergey Naumov.
>>>>
>>>> I've run into an interesting problem by using the above syntax. 
>>>> Apparently when I issue that command "blockdev --rereadpt
>>>> /dev/sde", it removes all the device's partition files (e.g.
>>>> /dev/sde1) and leaves the one for the drive itself (e.g.
>>>> /dev/sde).  If I unplug the device and plug it back in, the correct
>>>> device files populate again.  So it appears that mdev is working
>>>> right, but the blockdev is not.  Any ideas why blockdev would be
>>>> doing this?
>>>>
>>>> Dave
>>>
>>> Just to add a few more details.  I have a card reader that occupies
>>> /dev/sda through /dev/sdd.  If I insert an SD card with 2 partitions
>>> and wait for mdev to populate the device files, wait a few seconds,
>>> then issue the blockdev command, it wipes out those partition files
>>> too (e.g. /dev/sdb1).  If I issue the blockdev command on the device
>>> files for the card reader that don't have any inserted media, I get
>>> the error message "blockdev: can't open '/dev/sda': No medium
>>> found".  This tells me that blockdev can actually see if a device is
>>> present and that the devices files are populated correctly.  I just
>>> have no idea why it wouldn't be working correctly.  I've also tried:
>>>
>>> # hdparm -z /dev/sde
>>>
>>> /dev/sde:
>>>
>>> So you can see that it's failing too.  I think, however, hdparm
>>> isn't the best choice to use for USB attached devices.  Thoughts
>>> anyone?
>>>
>>> Dave
>>
>> Even more details - I wanted to see what dmesg was giving me, so I
>> browsed the output, tried the blockdev command again and noticed that
>> for every attempt at running it, I get the following entry appended
>> to the dmesg output:
>>
>> sd 5:0:0:0: [sde] Assuming drive cache: write through
>>  sde: sde1
>>
>> So perhaps blockdev is working correctly, there just happens to be a
>> problem getting the device files to populate.  Are the device files
>> created by blockdev itself as opposed to a helper of some type (e.g.
>> mdev)?
>>
>> Dave
>
> Ok, I thought I'd narrowed it down to a problem in the mdev processing
> script.  Since blockdev seemed like it was working correctly (per the
> output of dmesg), I decided to take a shot and change the mdev rule
> from using my script to just simply creating the device files on it's
> own (e.g. >%1).  Once I made that change and re-ran blockdev, the
> device files were populated correctly.  So... it appears as though
> there was a problem with the custom mdev script when creating the
> devices.  I have, however, tested and tested this script (not to say
> it's 100% bug free) so I decided to output the environment once again
> as a start to troubleshooting.  To my surprise I realized that the
> blockdev call is triggering both the add and remove actions of mdev. 
> This is why the device files were being removed (as part of the file
> system cleanup upon detaching devices).  Is this a bug in the blockdev
> or mdev applets?  I can't imagine why the add and remove actions would
> be triggered upon running a partition re-read via blockdev.  Thoughts?

IMHO wrong mailing list ... ask this the kernel guys.

blockdev just triggers partition reread in kernel, and doesn't deal with
device files either. mdev is a simple hotplug handler, called whenever
the kernel needs some help from a user space program to finish device
changes (etc). Neither of those programs is the originator of the
trouble you described.

... in my eyes that hotplug-ing stuff isn't perfect yet (not to call it
buggy in some cases) ... one of the reasons why I try to stay at more
statical solutions, at least where possible ... but those decisions are
like philosophy or religion, they depend on what you believe.

--
Harald


More information about the busybox mailing list