From: Hugo Mills <hugo@carfax.org.uk>
To: sri <toyours_sridhar@yahoo.co.in>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: btrfs on disk stability
Date: Tue, 26 May 2015 08:52:46 +0000 [thread overview]
Message-ID: <20150526085246.GC16826@carfax.org.uk> (raw)
In-Reply-To: <loom.20150526T103943-385@post.gmane.org>
[-- 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 --]
next prev parent reply other threads:[~2015-05-26 8:52 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-26 8:45 btrfs on disk stability sri
2015-05-26 8:52 ` Hugo Mills [this message]
2015-05-26 9:29 ` sri
2015-05-26 14:26 ` Hugo Mills
2015-05-26 16:26 ` Chris Murphy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150526085246.GC16826@carfax.org.uk \
--to=hugo@carfax.org.uk \
--cc=linux-btrfs@vger.kernel.org \
--cc=toyours_sridhar@yahoo.co.in \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox