atime/mtime for VG/PV

atime/mtime for VG/PV

[Marian Csontos]

Hi folks, as various issues with duplicates are being solved, I wondered if
it would be beneficial to include things like atime/mtime in metadata.

Actually mtime is already there in the VG metadata: seqno + timestamp.

So what would atime be?
Store a timestamp on activation of an LV in the VG? Write on any lvm
operation? Or write timestamp more frequently when there are active devices?

atime should be stored in PV metadata, even if there is no VG MDA - these
would benefit the most as there is no VG MDA and thus no "mtime".

When there are duplicates higher atime would be almost certainly the
correct device, unless user intends to use a LUN's snapshot, but that would
require an input from user anyway.

User MUST be able to turn it of ("noatime") in case of being slow for
hundreds/thousands of PVs.

Perhaps this would not have to be fsynced all the time, but then there may
be a chance for mismatch and for snapshot having higher timestamp than
original PV.

-- Martian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/lvm-devel/attachments/20211123/f8fd9453/attachment.htm>

atime/mtime for VG/PV

[David Teigland]

On Tue, Nov 23, 2021 at 04:58:20PM +0100, Marian Csontos wrote:
> Hi folks, as various issues with duplicates are being solved, I wondered if
> it would be beneficial to include things like atime/mtime in metadata.
> 
> Actually mtime is already there in the VG metadata: seqno + timestamp.
> 
> So what would atime be?
> Store a timestamp on activation of an LV in the VG? Write on any lvm
> operation? Or write timestamp more frequently when there are active devices?
> 
> atime should be stored in PV metadata, even if there is no VG MDA - these
> would benefit the most as there is no VG MDA and thus no "mtime".
> 
> When there are duplicates higher atime would be almost certainly the
> correct device, unless user intends to use a LUN's snapshot, but that would
> require an input from user anyway.
> 
> User MUST be able to turn it of ("noatime") in case of being slow for
> hundreds/thousands of PVs.
> 
> Perhaps this would not have to be fsynced all the time, but then there may
> be a chance for mismatch and for snapshot having higher timestamp than
> original PV.

It's interesting, it would be nice to think of some other problem(s) we
could address with it or something like it.  A local file might work in
place of metadata, depending on what it's used for.

The issue of duplicate PVs should soon go away with the devices file in
use.  When the devices file is used, a new cloned/copied PV will often not
be included in the devices file, so lvm won't see it.  But if it is, we
also store the WWID of each PV in the VG metadata, so if there are
duplicates we use the one with the correct WWID.