btrfs freeze/thaw when using with LVM2

btrfs freeze/thaw when using with LVM2

[sri]

Hi,

I would like to know if btrfs file system is created on LVM2 logical 
volumes, does freeze and thaw operations takes place for btrfs to make 
file system consistent??


If not is there a way (ioctl etc..) to run btrfs freeze/thaw before and 
after creating LVM2 snapshot of a btrfs file system?

Thank you in advance.

Re: btrfs freeze/thaw when using with LVM2

[Hugo Mills]

[-- Attachment #1: Type: text/plain, Size: 1531 bytes --]

On Mon, Apr 27, 2015 at 12:05:28PM +0000, sri wrote:
> Hi,
> 
> I would like to know if btrfs file system is created on LVM2 logical 
> volumes, does freeze and thaw operations takes place for btrfs to make 
> file system consistent??

   No, because the filesystem is *always* consistent, because of the
way that the CoW update mechanism works.

> If not is there a way (ioctl etc..) to run btrfs freeze/thaw before and 
> after creating LVM2 snapshot of a btrfs file system?

   As I said above, none is needed.

   HOWEVER, you shouldn't take LVM snapshots of a btrfs filesystem AT
ALL, if you have the original FS mounted on that system, or if you
plan on mounting the FS or its snapshots on that system. It's fine if
the only things mounting it are independent of the base system, and
don't see the snapshots (e.g. you're exporting LVs as block devices to
a VM host, and the snapshot is never seen by the VM; or you're
exporting LVs via NBD, and the remote system never sees the
snapshot).

   If, on the other hand, you're expecting to have /dev/mapper/foo
mounted, and then take a snapshot of it on the same system, you can
expect massive filesystem corruption, because the kernel can't
distinguish between the original block device and the snapshot, and
may try using the wrong one (or possibly both).

   Hugo.

-- 
Hugo Mills             | Someone's been throwing dead sheep down my Fun Well
hugo@... carfax.org.uk |
http://carfax.org.uk/  |
PGP: E2AB1DE4          |                                          Nick Gibbins

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: btrfs freeze/thaw when using with LVM2

[sri]

Hugo Mills <hugo <at> carfax.org.uk> writes:

> 
> On Mon, Apr 27, 2015 at 12:05:28PM +0000, sri wrote:
> > Hi,
> > 
> > I would like to know if btrfs file system is created on LVM2 logical 
> > volumes, does freeze and thaw operations takes place for btrfs to 
make 
> > file system consistent??
> 
>    No, because the filesystem is *always* consistent, because of the
> way that the CoW update mechanism works.
> 
> > If not is there a way (ioctl etc..) to run btrfs freeze/thaw before 
and 
> > after creating LVM2 snapshot of a btrfs file system?
> 
>    As I said above, none is needed.
> 
>    HOWEVER, you shouldn't take LVM snapshots of a btrfs filesystem AT
> ALL, if you have the original FS mounted on that system, or if you
> plan on mounting the FS or its snapshots on that system. It's fine if
> the only things mounting it are independent of the base system, and
> don't see the snapshots (e.g. you're exporting LVs as block devices to
> a VM host, and the snapshot is never seen by the VM; or you're
> exporting LVs via NBD, and the remote system never sees the
> snapshot).
> 
>    If, on the other hand, you're expecting to have /dev/mapper/foo
> mounted, and then take a snapshot of it on the same system, you can
> expect massive filesystem corruption, because the kernel can't
> distinguish between the original block device and the snapshot, and
> may try using the wrong one (or possibly both).
> 
>    Hugo.
> 

:) Thank you for your input. Past couple of hours, i am unable to figure 
it out what is happening with snapshot.

I am experiencing similar what you have explained.
taken a lvm snapshot using lvcreate of /dev/mapper/foo name 
/dev/mapper/foo-snap.

/dev/mapper/foo is mounted on /b1
and I have mounted /dev/mapper/foo-snap on /b2

after running mount command, i have seen there is a change in the mount 
entries. i.e. for both /b1 , /b2 mount point is changed to 
/dev/mapper/foo-snap.

And any write to original or to snap shot are reflecting on both.

This is strange considering that I wanted a consistent snapshot of 
entire btrfs filesystem at volume level.

Is there a way to achive this? or btrfs just cannot provide?

I am looking for a way make entire btrfs (which includes subvolumes in 
it) consistent so that I can take backup of the file system.

Re: btrfs freeze/thaw when using with LVM2

[Hugo Mills]

[-- Attachment #1: Type: text/plain, Size: 3674 bytes --]

On Mon, Apr 27, 2015 at 02:41:41PM +0000, sri wrote:
> Hugo Mills <hugo <at> carfax.org.uk> writes:
> 
> > 
> > On Mon, Apr 27, 2015 at 12:05:28PM +0000, sri wrote:
> > > Hi,
> > > 
> > > I would like to know if btrfs file system is created on LVM2 logical 
> > > volumes, does freeze and thaw operations takes place for btrfs to 
> make 
> > > file system consistent??
> > 
> >    No, because the filesystem is *always* consistent, because of the
> > way that the CoW update mechanism works.
> > 
> > > If not is there a way (ioctl etc..) to run btrfs freeze/thaw before 
> and 
> > > after creating LVM2 snapshot of a btrfs file system?
> > 
> >    As I said above, none is needed.
> > 
> >    HOWEVER, you shouldn't take LVM snapshots of a btrfs filesystem AT
> > ALL, if you have the original FS mounted on that system, or if you
> > plan on mounting the FS or its snapshots on that system. It's fine if
> > the only things mounting it are independent of the base system, and
> > don't see the snapshots (e.g. you're exporting LVs as block devices to
> > a VM host, and the snapshot is never seen by the VM; or you're
> > exporting LVs via NBD, and the remote system never sees the
> > snapshot).
> > 
> >    If, on the other hand, you're expecting to have /dev/mapper/foo
> > mounted, and then take a snapshot of it on the same system, you can
> > expect massive filesystem corruption, because the kernel can't
> > distinguish between the original block device and the snapshot, and
> > may try using the wrong one (or possibly both).
> > 
> >    Hugo.
> > 
> 
> :) Thank you for your input. Past couple of hours, i am unable to figure 
> it out what is happening with snapshot.
> 
> I am experiencing similar what you have explained.
> taken a lvm snapshot using lvcreate of /dev/mapper/foo name 
> /dev/mapper/foo-snap.
> 
> /dev/mapper/foo is mounted on /b1
> and I have mounted /dev/mapper/foo-snap on /b2
> 
> after running mount command, i have seen there is a change in the mount 
> entries. i.e. for both /b1 , /b2 mount point is changed to 
> /dev/mapper/foo-snap.
> 
> And any write to original or to snap shot are reflecting on both.

   Correct, this is the behaviour I was referring to above. You're
likely to see corrupt filesystems if you do this.

> This is strange considering that I wanted a consistent snapshot of 
> entire btrfs filesystem at volume level.
> 
> Is there a way to achive this? or btrfs just cannot provide?

   No, there's no way to manage it with the current btrfs code.

> I am looking for a way make entire btrfs (which includes subvolumes in 
> it) consistent so that I can take backup of the file system.

   You're probably looking for some variant on the recursive snapshots
idea. I know at least a couple of people have ideas on how to do this,
but I don't think any of the ideas are close to completion.

   Instead, I would suggest looking at which pieces of your system are
*required* to be consistent, and put those on their own subvolume(s).
For example, in a multi-user system, I would be very surprised if the
individual users' home subvolumes had to be snapshotted as a whole --
nobody will care if person A has their snapshot taken a few seconds
(or even half an hour) before person B. Work out what you can get away
with non-atomically for your needs, rather than simply requiring a
complete atomic snapshot of everything, because if you're using
multiple subvolumes, that's simply not going to happen right now.

   Hugo.

-- 
Hugo Mills             | Two things came out of Berkeley in the 1960s: LSD
hugo@... carfax.org.uk | and Unix. This is not a coincidence.
http://carfax.org.uk/  |
PGP: E2AB1DE4          |

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: btrfs freeze/thaw when using with LVM2

[Roman Mamedov]

[-- Attachment #1: Type: text/plain, Size: 445 bytes --]

On Mon, 27 Apr 2015 14:55:49 +0000
Hugo Mills <hugo@carfax.org.uk> wrote:

> > This is strange considering that I wanted a consistent snapshot of 
> > entire btrfs filesystem at volume level.
> > 
> > Is there a way to achive this? or btrfs just cannot provide?
> 
>    No, there's no way to manage it with the current btrfs code.

Why not. fsfreeze, dd to a file (optionally with compression), unfreeze.

-- 
With respect,
Roman

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: btrfs freeze/thaw when using with LVM2

[Hugo Mills]

[-- Attachment #1: Type: text/plain, Size: 870 bytes --]

On Mon, Apr 27, 2015 at 10:34:42PM +0500, Roman Mamedov wrote:
> On Mon, 27 Apr 2015 14:55:49 +0000
> Hugo Mills <hugo@carfax.org.uk> wrote:
> 
> > > This is strange considering that I wanted a consistent snapshot of 
> > > entire btrfs filesystem at volume level.
> > > 
> > > Is there a way to achive this? or btrfs just cannot provide?
> > 
> >    No, there's no way to manage it with the current btrfs code.
> 
> Why not. fsfreeze, dd to a file (optionally with compression), unfreeze.

   OK, point taken, but if you want to use the frozen volume to make a
file-level backup of the FS contents, you've still got to turn it into
a block device and mount it... at which point, you get hit by the
explosion again...

   Hugo.

-- 
Hugo Mills             | The future isn't what it used to be.
hugo@... carfax.org.uk |
http://carfax.org.uk/  |
PGP: E2AB1DE4          |

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: btrfs freeze/thaw when using with LVM2

[sri]

Hugo Mills <hugo <at> carfax.org.uk> writes:

> 
> On Mon, Apr 27, 2015 at 10:34:42PM +0500, Roman Mamedov wrote:
> > On Mon, 27 Apr 2015 14:55:49 +0000
> > Hugo Mills <hugo <at> carfax.org.uk> wrote:
> > 
> > > > This is strange considering that I wanted a consistent snapshot 
of 
> > > > entire btrfs filesystem at volume level.
> > > > 
> > > > Is there a way to achive this? or btrfs just cannot provide?
> > > 
> > >    No, there's no way to manage it with the current btrfs code.
> > 
> > Why not. fsfreeze, dd to a file (optionally with compression), 
unfreeze.
> 
>    OK, point taken, but if you want to use the frozen volume to make a
> file-level backup of the FS contents, you've still got to turn it into
> a block device and mount it... at which point, you get hit by the
> explosion again...
> 
>    Hugo.
> 


If I am not wrong, chunk tree represents the allocaiton block of entire 
file system. I could copy and replicate ( which will be less time 
consume) on alternate disk(s). 

For this kind of backup, either lvm level consistency or freeze/thaw 
would help.

Re: btrfs freeze/thaw when using with LVM2

[Piotr Pawłow]

On 27.04.2015 o 14:15, Hugo Mills wrote:
> HOWEVER, you shouldn't take LVM snapshots of a btrfs filesystem AT ALL

I'd like to add, that generally when working with LVM and BTRFS, it's 
probably a good idea to always use "device=" mount option to make it 
scan only specified devices instead of all. I'd learned that the hard 
way, when I enabled SSD caching, and got massive corruption, because 
BTRFS mixed up cached devices with cache-origin devices. Now I have 
"device=/dev/mapper/vg-home1,device=/dev/mapper/vg-home2" in mount 
options in my fstab, and I can use LVM cache without worrying that 
things will get mixed up again.