linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Christoph Anton Mitterer <calestyo@scientia.net>
To: Hugo Mills <hugo@carfax.org.uk>
Cc: Duncan <1i5t5.duncan@cox.net>, linux-btrfs@vger.kernel.org
Subject: Re: subvols and parents - how?
Date: Wed, 25 Nov 2015 00:20:09 +0100	[thread overview]
Message-ID: <1448407209.21291.112.camel@scientia.net> (raw)
In-Reply-To: <20151124215542.GT24333@carfax.org.uk>

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

On Tue, 2015-11-24 at 21:55 +0000, Hugo Mills wrote:
>    In practice, new content is checked by a number of people when
> it's
> put in, so the case of someone putting random poorly-thought-out crap
> in the wiki isn't particularly likely to happen.
Well... it may work in 99% cases... but there could something slip
through, which isn't as easy the case in manpages, which also tend to
be less messy than the huge pile of wiki pages where similar/related
things are described on different pages.

Imagine a case, a non-experienced user update the wiki saying that --
repair should be used, he may not even doing it in bad faith, perhaps
he had success with it and now writes a recipe.
It may take a while until someone of the more experienced guys notices
that and corrects it.
But if ", in the meantime had some fs corruptions,... I may experience
already severe problems by following that suggestion... (and while I do
have many backups of all my data, others may not, and if their life's
data is concerned, they'd be screwed).

So even if it takes you just a few hours to correct such rubbish, you
know that Murphy's law may still hit n people during that time ;-)


> Please feel free to add the things you'd like to see. As I said
> above, we do check the docs on the wiki as they're changed, so if
> you're wrong on some details, it won't be a major issue for very
> long. If you want to discuss details before you write something,
> start
> a conversation -- either on here, or on IRC (or even on the Talk
> pages
> of the wiki).
Well I can write a list together of things which I think should be part
of some more general documentation (i.e. less documentation about
options of the tools)... questions a complete newcomer to btrfs may
have who needs however more than "just a filesystem".


>    Note that the "parent" of send -p and of snapshots is not the same
> relationship as the "parent" (containing subvol) of the tree
> structure. This is an awkward nomenclature problem, and I'm not sure
> how to fix it.
Yeah, that was clear... :-)
Maybe call the "parent" from send -p "base" or something like that...
IMHO that would fit more as the parent there is more like a
"fundament".

Anyway, it's still not as bad as the usage of "RAID1" ;-)


> because
> you can't rename a subvol across another subvol boundary.
That's not quite clear to me... I had subvols like that:
/top/root/below-root
/top/below-top
and was able to move that to:
/top/root/below-top
/top/below-root

i.e. not just changing names but swapping as in:
mv /top/root/below-top /top/tmp
mv /top/below-root /top/root/below-root
mv /top/tmp /top/below-top

with top, root, below-top and below-root all being the same subvols


Thanks a lot for your explanations :)

Chris.

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5313 bytes --]

  reply	other threads:[~2015-11-24 23:20 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-24  4:56 subvols and parents - how? Christoph Anton Mitterer
2015-11-24  8:29 ` Duncan
2015-11-24 21:25   ` Christoph Anton Mitterer
2015-11-24 21:55     ` Hugo Mills
2015-11-24 23:20       ` Christoph Anton Mitterer [this message]
2015-11-24 23:30         ` Hugo Mills
2015-11-24 23:38           ` Christoph Anton Mitterer
2015-11-27  1:02     ` Duncan
2015-12-09  4:36       ` Christoph Anton Mitterer
2015-12-09 10:53         ` Duncan
2015-12-09 19:04           ` Austin S Hemmelgarn
2015-12-10  3:56             ` Duncan
2015-12-10 12:31               ` Austin S Hemmelgarn
2015-12-12 19:58           ` Christoph Anton Mitterer
2015-11-27  2:02     ` Duncan
2015-12-09  4:38       ` Christoph Anton Mitterer
2015-12-09 11:26         ` Duncan
2015-12-10 21:13           ` subvols, ro- and bind mounts " Christoph Anton Mitterer
2015-12-10 22:36             ` S.J.
2015-12-10 23:41               ` Christoph Anton Mitterer
2015-12-11  2:32               ` Chris Murphy
2015-12-12 20:27                 ` Christoph Anton Mitterer
2015-12-12  2:32           ` subvols and parents " Christoph Anton Mitterer
2015-12-12  3:07             ` Christoph Anton Mitterer
2015-12-12 10:20             ` Duncan
2015-12-09 14:49       ` Axel Burri

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=1448407209.21291.112.camel@scientia.net \
    --to=calestyo@scientia.net \
    --cc=1i5t5.duncan@cox.net \
    --cc=hugo@carfax.org.uk \
    --cc=linux-btrfs@vger.kernel.org \
    /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;
as well as URLs for NNTP newsgroup(s).