2012-01-13 20:00:12

by Asdo

[permalink] [raw]
Subject: Filesystem freeze vs blockdevice snapshot

Hello all,
please excuse the silly question...

What is the benefit of performing an ext4 fs freeze before taking a
snapshot of the underlying block device with LVM2 ?

Is the freeze step useful or I can go with the snapshot directly?

And/or is there another use case for the freeze?

Thank you


2012-01-16 17:03:03

by Asdo

[permalink] [raw]
Subject: Re: Filesystem freeze vs blockdevice snapshot

[sorry for double posting : had forgot to remove html]

Thanks but it's still not clear to me.
What do you mean with "clean fs"? is that in any way different from an
image after a sudden power loss?
Secondarily, how can LVM know what filesystem is underneath and call the
proper freeze? That's a bare block device, there might not even be a
filesystem under LVM; or it might be exported via iSCSI to an XYZ
operating system using the Xyzfs filesystem which Linux knows nothing
about...
Thank you

On 01/14/12 19:33, Amir Goldstein wrote:
> LVM2 already does the fs freeze for you before taking the snapshot.
> it's the only way to get a block device snapshot of a "clean" fs.
> hope that answers your question.
>
> On Fri, Jan 13, 2012 at 5:30 PM, Asdo <[email protected]
> <mailto:[email protected]>> wrote:
>
> Hello all,
> please excuse the silly question...
>
> What is the benefit of performing an ext4 fs freeze before taking
> a snapshot of the underlying block device with LVM2 ?
>
> Is the freeze step useful or I can go with the snapshot directly?
>
> And/or is there another use case for the freeze?
>
> Thank you
> --
> To unsubscribe from this list: send the line "unsubscribe
> linux-ext4" in
> the body of a message to [email protected]
> <mailto:[email protected]>
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>



2012-01-16 19:16:59

by Jan Kara

[permalink] [raw]
Subject: Re: Filesystem freeze vs blockdevice snapshot

On Mon 16-01-12 18:03:07, Asdo wrote:
> Thanks but it's still not clear to me.
> What do you mean with "clean fs"? is that in any way different from
> an image after a sudden power loss?
Yes. It is different:
a) the filesystem will be marked as clean so journal will not be replayed
on mount of the snapshot
b) dirty data will be flushed to disk during freezing so you will get most
recent file content. On sudden power failure you might miss quite a lot of
data.

> Secondarily, how can LVM know what filesystem is underneath and call
> the proper freeze? That's a bare block device, there might not even
> be a filesystem under LVM; or it might be exported via iSCSI to an
> XYZ operating system using the Xyzfs filesystem which Linux knows
> nothing about...
Well, if the kernel has the device mounted, it knows it and it can call
proper fs method to freeze the filesystem. If it is some more complex
scenario (like export to other host), then kernel doesn't know enough and
doesn't attempt to freeze the filesystem.

Honza

> On 01/14/12 19:33, Amir Goldstein wrote:
> >LVM2 already does the fs freeze for you before taking the snapshot.
> >it's the only way to get a block device snapshot of a "clean" fs.
> >hope that answers your question.
> >
> >On Fri, Jan 13, 2012 at 5:30 PM, Asdo <[email protected]
> ><mailto:[email protected]>> wrote:
> >
> > Hello all,
> > please excuse the silly question...
> >
> > What is the benefit of performing an ext4 fs freeze before taking
> > a snapshot of the underlying block device with LVM2 ?
> >
> > Is the freeze step useful or I can go with the snapshot directly?
> >
> > And/or is there another use case for the freeze?
> >
> > Thank you
> > --
> > To unsubscribe from this list: send the line "unsubscribe
> > linux-ext4" in
> > the body of a message to [email protected]
> > <mailto:[email protected]>
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> >
> >
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Jan Kara <[email protected]>
SUSE Labs, CR