* btrfs on disk stability
@ 2015-05-26 8:45 sri
2015-05-26 8:52 ` Hugo Mills
0 siblings, 1 reply; 5+ messages in thread
From: sri @ 2015-05-26 8:45 UTC (permalink / raw)
To: linux-btrfs
Hi,
According to btrfs wiki page, under "Stability status" it is written that
"The filesystem disk format is no longer unstable".
Does this mean if there are more I/Os are going on a btrfs file system,
copy of entire disk (all disk blocks) gives a stable disk?
Just to elaborate more, if btrfs file system is created on 2 disks
/dev/sda and /dev/sdb and if I start copying blocks of sda and sdb to sdc
and sdc respectively by just opening file handlers of sda and sdb and
mounting the new copy via /dev/sdc and /dev/sdd will give consistent file
system??
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: btrfs on disk stability
2015-05-26 8:45 btrfs on disk stability sri
@ 2015-05-26 8:52 ` Hugo Mills
2015-05-26 9:29 ` sri
0 siblings, 1 reply; 5+ messages in thread
From: Hugo Mills @ 2015-05-26 8:52 UTC (permalink / raw)
To: sri; +Cc: linux-btrfs
[-- Attachment #1: Type: text/plain, Size: 1752 bytes --]
On Tue, May 26, 2015 at 08:45:06AM +0000, sri wrote:
> Hi,
>
> According to btrfs wiki page, under "Stability status" it is written that
>
> "The filesystem disk format is no longer unstable".
>
> Does this mean if there are more I/Os are going on a btrfs file system,
> copy of entire disk (all disk blocks) gives a stable disk?
No, it means that the format isn't changing in incompatible ways
any more. You're guaranteed that if you upgrade your kernel, the FS
will still be readable on the new kernel. (And, if you don't enable
any extra features with btrfstune, that the kernel will still be
readable if you downgrade to the earlier kernel you were using).
> Just to elaborate more, if btrfs file system is created on 2 disks
> /dev/sda and /dev/sdb and if I start copying blocks of sda and sdb to sdc
> and sdc respectively by just opening file handlers of sda and sdb and
> mounting the new copy via /dev/sdc and /dev/sdd will give consistent file
> system??
That's always the case, with the very large caveat that you remove
/dev/sdc and /dev/sdd from the system before you try mounting anything
related to that FS. Making block level copies of btrfs filesystems and
leaving them visible to the same kernel as the originals is a very bad
idea, and can cause massive FS corruption.
It's OK to make the copy, but not to try mounting the FS with both
copies present, as the kernel will see both copies as the same
filesystem (because they have the same UUID), and it will get very
confused about which device(s) it's meant to be writing to.
Hugo.
--
Hugo Mills | Q: What goes, "Pieces of seven! Pieces of seven!"?
hugo@... carfax.org.uk | A: A parroty error.
http://carfax.org.uk/ |
PGP: E2AB1DE4 |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: btrfs on disk stability
2015-05-26 8:52 ` Hugo Mills
@ 2015-05-26 9:29 ` sri
2015-05-26 14:26 ` Hugo Mills
0 siblings, 1 reply; 5+ messages in thread
From: sri @ 2015-05-26 9:29 UTC (permalink / raw)
To: linux-btrfs
Hugo Mills <hugo <at> carfax.org.uk> writes:
>
> On Tue, May 26, 2015 at 08:45:06AM +0000, sri wrote:
> > Hi,
> >
> > According to btrfs wiki page, under "Stability status" it is written
that
> >
> > "The filesystem disk format is no longer unstable".
> >
> > Does this mean if there are more I/Os are going on a btrfs file
system,
> > copy of entire disk (all disk blocks) gives a stable disk?
>
> No, it means that the format isn't changing in incompatible ways
> any more. You're guaranteed that if you upgrade your kernel, the FS
> will still be readable on the new kernel. (And, if you don't enable
> any extra features with btrfstune, that the kernel will still be
> readable if you downgrade to the earlier kernel you were using).
>
> > Just to elaborate more, if btrfs file system is created on 2 disks
> > /dev/sda and /dev/sdb and if I start copying blocks of sda and sdb
to sdc
> > and sdc respectively by just opening file handlers of sda and sdb
and
> > mounting the new copy via /dev/sdc and /dev/sdd will give consistent
file
> > system??
>
> That's always the case, with the very large caveat that you remove
> /dev/sdc and /dev/sdd from the system before you try mounting anything
> related to that FS. Making block level copies of btrfs filesystems and
> leaving them visible to the same kernel as the originals is a very bad
> idea, and can cause massive FS corruption.
>
> It's OK to make the copy, but not to try mounting the FS with both
> copies present, as the kernel will see both copies as the same
> filesystem (because they have the same UUID), and it will get very
> confused about which device(s) it's meant to be writing to.
>
Thank you Hugo,
copies of disk will not be there once block level copy is done. Assume
that sdc and sdd (which are used for copy sda and sdb) are ISCSI disks
from different machine and as soon as disk copy sda->sdc and sdb->sdd is
done, I will remove both disks and use it on other machine.
In this case
1) After copy at disk level whether the btrfs on sdc and sdd will be in
consistent state? even though there are any IOs on original disks sda
and sdb?
My guess is no but I am not sure
2) new disks sdc and sdd can be mounted on another machine where btrfs
fs is supported ?
> Hugo.
>
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: btrfs on disk stability
2015-05-26 9:29 ` sri
@ 2015-05-26 14:26 ` Hugo Mills
2015-05-26 16:26 ` Chris Murphy
0 siblings, 1 reply; 5+ messages in thread
From: Hugo Mills @ 2015-05-26 14:26 UTC (permalink / raw)
To: sri; +Cc: linux-btrfs
[-- Attachment #1: Type: text/plain, Size: 3334 bytes --]
On Tue, May 26, 2015 at 09:29:25AM +0000, sri wrote:
> Hugo Mills <hugo <at> carfax.org.uk> writes:
>
> >
> > On Tue, May 26, 2015 at 08:45:06AM +0000, sri wrote:
> > > Hi,
> > >
> > > According to btrfs wiki page, under "Stability status" it is written
> that
> > >
> > > "The filesystem disk format is no longer unstable".
> > >
> > > Does this mean if there are more I/Os are going on a btrfs file
> system,
> > > copy of entire disk (all disk blocks) gives a stable disk?
> >
> > No, it means that the format isn't changing in incompatible ways
> > any more. You're guaranteed that if you upgrade your kernel, the FS
> > will still be readable on the new kernel. (And, if you don't enable
> > any extra features with btrfstune, that the kernel will still be
> > readable if you downgrade to the earlier kernel you were using).
> >
> > > Just to elaborate more, if btrfs file system is created on 2 disks
> > > /dev/sda and /dev/sdb and if I start copying blocks of sda and sdb
> to sdc
> > > and sdc respectively by just opening file handlers of sda and sdb
> and
> > > mounting the new copy via /dev/sdc and /dev/sdd will give consistent
> file
> > > system??
> >
> > That's always the case, with the very large caveat that you remove
> > /dev/sdc and /dev/sdd from the system before you try mounting anything
> > related to that FS. Making block level copies of btrfs filesystems and
> > leaving them visible to the same kernel as the originals is a very bad
> > idea, and can cause massive FS corruption.
> >
> > It's OK to make the copy, but not to try mounting the FS with both
> > copies present, as the kernel will see both copies as the same
> > filesystem (because they have the same UUID), and it will get very
> > confused about which device(s) it's meant to be writing to.
> >
>
> Thank you Hugo,
> copies of disk will not be there once block level copy is done. Assume
> that sdc and sdd (which are used for copy sda and sdb) are ISCSI disks
> from different machine and as soon as disk copy sda->sdc and sdb->sdd is
> done, I will remove both disks and use it on other machine.
>
> In this case
> 1) After copy at disk level whether the btrfs on sdc and sdd will be in
> consistent state? even though there are any IOs on original disks sda
> and sdb?
> My guess is no but I am not sure
If you're trying to copy a filesystem that's in use, then no, you
can't expect the copies to be consistent.
Imagine: At the point where you've copied half the disk, and the FS
makes two updates which depend on each other -- one in the piece
you've already copied, and one in the piece you haven't copied
yet. Also, by this point, you've got the situation I warned against
above: multiple copies of a filesystem that's mounted, so your FS is
probably already damaged beyond repair. Doing it with a read-only
mount of the FS might be possible.
Basically, you can only do this reliably if the filesystem is not
mounted.
> 2) new disks sdc and sdd can be mounted on another machine where btrfs
> fs is supported ?
Yes.
Hugo.
--
Hugo Mills | Do not meddle in the affairs of wizards, for they
hugo@... carfax.org.uk | are subtle, and quick to anger.
http://carfax.org.uk/ |
PGP: E2AB1DE4 | J.R.R. Tolkein
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: btrfs on disk stability
2015-05-26 14:26 ` Hugo Mills
@ 2015-05-26 16:26 ` Chris Murphy
0 siblings, 0 replies; 5+ messages in thread
From: Chris Murphy @ 2015-05-26 16:26 UTC (permalink / raw)
To: Btrfs BTRFS
I'm not really understanding the use case. Is this for one time copy
of a Btrfs file system or a need to keep the copies in sync? Because
this sounds like a better fit for rsync, btrfs send/receive, or drdb.
The part especially where I'm getting confused is where you say "start
copying blocks of sda to sdc" and yet you refer to "file handler" and
"mounting the new copy". I can't really tell if this is strictly a
block copy e.g. using dd, or if you're using cp/rsync -a or what. And
then, why do you need to mount the copy?
Chris Murphy
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2015-05-26 16:26 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-05-26 8:45 btrfs on disk stability sri
2015-05-26 8:52 ` Hugo Mills
2015-05-26 9:29 ` sri
2015-05-26 14:26 ` Hugo Mills
2015-05-26 16:26 ` Chris Murphy
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox