All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.