* [linux-lvm] File-system uuid on LVM snapshot
[not found] <1208338730.18211142.1401956193776.JavaMail.zimbra@redhat.com>
@ 2014-06-05 8:26 ` Rajesh Joseph
2014-06-05 9:19 ` Zdenek Kabelac
0 siblings, 1 reply; 4+ messages in thread
From: Rajesh Joseph @ 2014-06-05 8:26 UTC (permalink / raw)
To: linux-lvm
Hi all,
Origin volume and snapshot volume share the same file-system UUID. So after the snapshot we fix the uuid by running xfs_admin or tune2fs.
Do you have any recommendation or best practice in this regard?
Thanks & Regards,
Rajesh
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [linux-lvm] File-system uuid on LVM snapshot
2014-06-05 8:26 ` [linux-lvm] File-system uuid on LVM snapshot Rajesh Joseph
@ 2014-06-05 9:19 ` Zdenek Kabelac
2014-06-05 9:29 ` Rajesh Joseph
0 siblings, 1 reply; 4+ messages in thread
From: Zdenek Kabelac @ 2014-06-05 9:19 UTC (permalink / raw)
To: linux-lvm
Dne 5.6.2014 10:26, Rajesh Joseph napsal(a):
> Hi all,
>
> Origin volume and snapshot volume share the same file-system UUID. So after the snapshot we fix the uuid by running xfs_admin or tune2fs.
> Do you have any recommendation or best practice in this regard?
>
With thin pools and thin volumes - snapshot of thin volume is now created
'inactive' and it's skipped from default activation (you could always
override skip with -K i.e. : lvchange -ay -K vg/mythinsnap)
So with thins you should mostly have only a single volume active with the FS
UUID. If you happen to have multiple volumes active and you need to mount xfs
filesystem - use 'nouuid' (and eventually norecovery for read-only
activated snapshots) mount options.
For old-snapshosts - all volumes need to be available/active - so you need to
use 'nouuid' option always.
I don't see much point in changing FS UUID on your snapshot - unless of
course you plan to use snapshots as different volumes with just a 'single'
starting point (i.e. preinstalled tree of files)
Regards
Zdenek
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [linux-lvm] File-system uuid on LVM snapshot
2014-06-05 9:19 ` Zdenek Kabelac
@ 2014-06-05 9:29 ` Rajesh Joseph
2014-06-05 10:31 ` Zdenek Kabelac
0 siblings, 1 reply; 4+ messages in thread
From: Rajesh Joseph @ 2014-06-05 9:29 UTC (permalink / raw)
To: LVM general discussion and development
Thanks Zdenek for the quick reply.
We are using thin volumes and thin snapshot, but we need all or most snapshots active. Therefore we are enabling the snapshot by-default.
As you suggested we can have a workaround to mount those snapshot volumes by using 'nouuid' option.
But the problem is in most of our use case the origin volume is mounted using the /etc/fstab. And here the mount entry is made using UUID.
So in some cases instead of Origin volume the snapshot volume get mounted.
Thanks & Regards,
Rajesh
----- Original Message -----
> From: "Zdenek Kabelac" <zkabelac@redhat.com>
> To: linux-lvm@redhat.com
> Sent: Thursday, June 5, 2014 2:49:51 PM
> Subject: Re: [linux-lvm] File-system uuid on LVM snapshot
>
> Dne 5.6.2014 10:26, Rajesh Joseph napsal(a):
> > Hi all,
> >
> > Origin volume and snapshot volume share the same file-system UUID. So after
> > the snapshot we fix the uuid by running xfs_admin or tune2fs.
> > Do you have any recommendation or best practice in this regard?
> >
>
>
> With thin pools and thin volumes - snapshot of thin volume is now created
> 'inactive' and it's skipped from default activation (you could always
> override skip with -K i.e. : lvchange -ay -K vg/mythinsnap)
>
> So with thins you should mostly have only a single volume active with the FS
> UUID. If you happen to have multiple volumes active and you need to mount
> xfs
> filesystem - use 'nouuid' (and eventually norecovery for read-only
> activated snapshots) mount options.
>
> For old-snapshosts - all volumes need to be available/active - so you need to
> use 'nouuid' option always.
>
> I don't see much point in changing FS UUID on your snapshot - unless of
> course you plan to use snapshots as different volumes with just a 'single'
> starting point (i.e. preinstalled tree of files)
>
> Regards
>
> Zdenek
>
>
> _______________________________________________
> linux-lvm mailing list
> linux-lvm@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-lvm
> read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
>
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [linux-lvm] File-system uuid on LVM snapshot
2014-06-05 9:29 ` Rajesh Joseph
@ 2014-06-05 10:31 ` Zdenek Kabelac
0 siblings, 0 replies; 4+ messages in thread
From: Zdenek Kabelac @ 2014-06-05 10:31 UTC (permalink / raw)
To: linux-lvm
Dne 5.6.2014 11:29, Rajesh Joseph napsal(a):
> Thanks Zdenek for the quick reply.
>
> We are using thin volumes and thin snapshot, but we need all or most snapshots active. Therefore we are enabling the snapshot by-default.
> As you suggested we can have a workaround to mount those snapshot volumes by using 'nouuid' option.
> But the problem is in most of our use case the origin volume is mounted using the /etc/fstab. And here the mount entry is made using UUID.
> So in some cases instead of Origin volume the snapshot volume get mounted.
So this rather looks like you are not using 'snapshot' as snapshot but rather
as a quick COW device clone - where you obviously need to change identifiers,
since they are used later independently. (something like we do with
'vgimportclone' where we duplicate VG)
Maybe it might be worth to think about fsadm extension to support filesystem
cloning as a built-in feature which would handle change if fs UUID across
different filesystems...
Regards
Zdenek
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2014-06-05 10:31 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <1208338730.18211142.1401956193776.JavaMail.zimbra@redhat.com>
2014-06-05 8:26 ` [linux-lvm] File-system uuid on LVM snapshot Rajesh Joseph
2014-06-05 9:19 ` Zdenek Kabelac
2014-06-05 9:29 ` Rajesh Joseph
2014-06-05 10:31 ` Zdenek Kabelac
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.