Comment 24 for bug 910379

> On 1/5/2012 4:05 PM, Curtis Gedak wrote:
>> Phillip, are you able to bring this problem with blkid searching non-
>> existent floppy drive to the attention of the right people?
>
> I don't think it is considered a bug by anyone. If the bios claims you
> have a floppy, then the kernel thinks you have a floppy. If you try to
> access the floppy, the the kernel tries it's hardest to access it, even
> though it keeps failing.

I do agree Phillip that the root cause of the problem is an incorrectly configured BIOS. Having said that, it would be nice if blkid could handle this situation better instead of scanning for a very long time.

Another reason to bring this to the attention of the blkid people is that according to Carla, the previous versions of blkid does not appear to exhibit this behaviour. Hence this looks like a recently introduced change/problem.

> > In the past if I changed the label of a partition with GParted and then
> > called blkid, I received the cached result which was the old label.
> > That is why I used the "-c /dev/null" to force blkid to re-read the
> > information.
> >
> > I have not tested to see if blkid still has this same behaviour.
>
> Right, if you call it before udev has had a chance to run it to update
> the cache, that would happen. If you are changing the label, why don't
> you just update your cached label directly instead of querying blkid again?

The main reason to not update the GParted cache directly is that then we won't know if the label write really succeeded. The only way to be sure the label was written correctly is to physically re-read the label from the disk. By re-reading the disk label we can learn if the label was truncated or not written for some reason.

Regarding waiting for udev to update it's cache, do you think a "udevadm settle" would be sufficient before a call to "blkid" to ensure that has up-to-date information?