[linux-lvm] Why does every lvm command insist on touching every pv?

[Takahiro Yasui]

On 06/17/10 04:23, Zdenek Kabelac wrote:
> Dne 16.6.2010 21:27, Takahiro Yasui napsal(a):
>> On 06/16/10 05:30, Zdenek Kabelac wrote:
>>> Dne 16.6.2010 02:34, Phillip Susi napsal(a):
>>>> On 06/15/2010 04:41 PM, Takahiro Yasui wrote:
>> ...
>>>> What if I don't want ANY devices to be scanned every time an lvm command
>>>> is run?  Shouldn't they be scanned once when udev first detects they
>>>> have been attached, and no more?  I thought removing /dev from the scan=
>>>> line would do that, but it didn't.
>>>>
...
>> It is helpful if udev can handle this issue, but I'm wondering how it can
>> do it.
> 
> I'm not working on this part, but AFAIK, once we could start 'trust' udev, we
> can keep persistent cache aware of any changes that might have happened to
> devices listed in metadata. Implementation details are still 'moving topic'.
> 
> Obviously you can not skip write/update access to metadata areas, but it
> should be possible to avoid scanning for 'read-only' data access.

Thank you for your explanation. Yes, I agree that it is possible to avoid
scanning for 'read-only' data access, but I also believe it is possible for
'write' adata access.
 
> Also there is another thing in progress - metadata-balance code - where you
> essentially do not need to read/write metadata from/to every PV in VG - but
> just on reasonable safe amount of them - i.e. 5 from 100 of PVs - the rest of
> them is marked invisible (different from pvcreate --metadatasize 0)

AFAIK, metadata-balance feature would reduce the number of disk accesses,
but I believe that the goal is to access PVs related to the VG which lvm
command is going to manipulate. Introducing metadata cache feature on disk
or a kind of daemon managing all metadatas, or using /etc/lvm/backup could
be solution.

I hope we could continue discussing this topic on lvm-devel?

Thanks,
Taka