Comment 103 for bug 332270

Revision history for this message
Alasdair G. Kergon (agk2) wrote : Re: [Bug 332270] Re: udev repeatedly generates "change" events for the same block device(s)

On Mon, Feb 23, 2009 at 04:45:18PM -0000, Scott James Remnant wrote:
> There are two parts to this bug.
> The actual bug is being caused by "lvm vgscan" opening all block devices
> on the system writable and then closing them again, which triggers the
> inotify event. There seems to be no reason they cannot be opened
> readonly, since the only thing it does is call fstat() and read() on
> them.

Good luck:-)

> Part #1 of the fix will be a patch to LVM to only open block devices
> with O_RDONLY

I don't know which lines are the problem, but it's probably opening
them for write in case it decides it needs to fix up the metadata.
(It can't handle promotion from read->write so if any possible code path
includes a write, it opens with write access.)

> Since the devices include any LVM PVs (which is what it's looking for),
> this gives you a recursive loop where LVM PVs appear to have been
> changed, so udev calls "lvm vgscan" again to update its tables.

That's what needs fixing - vgscan is just the wrong approach here.
Upstream (2.02.45) we made a start with a new class of 'pvs' output
fields, Physical Volume Label Fields, e.g. pvs -o pv_name.
If only these fields are specified, the code is meant not to scan
and only access the devices specified on the command line.

We need to sort out the right interface for adding one device at a
time so you don't need vgscan at all.

Alasdair
--
<email address hidden>