https://bugzilla.novell.com/show_bug.cgi?id=773058
https://bugzilla.novell.com/show_bug.cgi?id=773058#c43
Jiri Kosina changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |puzel@suse.com
InfoProvider|nfbrown@suse.com |werner@suse.com
--- Comment #43 from Jiri Kosina 2014-01-09 23:34:39 CET ---
OK, I think I know what is happening.
First things first:
- the origin of all this is, that /proc/partitions is now listing fd0 and sd0,
which wasn't the case before. Whether this is correct or not is debatable by
itself, but not really the core of the problem
- both mdadm and libblkid are using /proc/partitions to gather the list of
block
devices to operate on. This explains why older distributions don't touch fd0,
as it's simply not listed in /proc/partitions
- mdadm opens /dev/fd0, performs just a few read() iterations when it's trying
to autodetect superblock type, and then gives up. This takes 1-2 minutes.
- what I believe is the real problem, is libblkid. It opens /dev/fd0,
issues ioctl(BLKGETSIZE64), and starts issuing read() calls. When the floppy
drive/controller is there, but it's empty, the read() return ENXIO. blkid
ignores the error and keeps spinning in the loop. Which is not the right
thing
to do.
I have never seen util-linux sources before, but looking at it for a few
minutes, I think the problem is the loop in blkid_probe_get_idmag().
It calls blkid_probe_get_buffer(), which issues the actual read() that
returns
ENXIO. That causes blkid_probe_get_buffer() to return NULL back to
blkid_probe_get_idmag(). The if branch is then not taken (buf is NULL), mag
is
incremented, and loop restarted. And again, and again ...
Adding Werner and Petr (I am not really sure who is proper util-linux
maintainer, if someone else is appropriate, please redirect accordingly).
Thanks.
--
Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.