linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andreas Philipp <philipp.andreas@gmail.com>
To: Hugo Mills <hugo@carfax.org.uk>,
	Stephane Chazelas <stephane_chazelas@yahoo.fr>,
	linux-btrfs <linux-btrfs@vger.kernel.org>
Subject: Re: strange btrfs sub list output
Date: Fri, 27 May 2011 12:06:44 +0200	[thread overview]
Message-ID: <4DDF77B4.4040505@gmail.com> (raw)
In-Reply-To: <20110527094523.GA12089@carfax.org.uk>


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
 
On 27.05.2011 11:45, Hugo Mills wrote:
> On Fri, May 27, 2011 at 10:30:29AM +0100, Stephane Chazelas wrote:
>> 2011-05-27 10:12:24 +0100, Hugo Mills:
>> [skipped useful clarification]
>>>
>>> That's all rather dense, and probably too much information. Hope
>>> it's helpful, though.
>> [...]
>>
>> It is, thanks.
>>
>> How would one end up in a situation where the output of "btrfs
>> sub list ." has:
>>
>> ID 287 top level 285 path data
>>
>> How could a "subvolume 285" become a "top level"?
>
>> How does one get a subvolume with a top-level other than "5"?
>
> This just means that subvolume 287 was created (somewhere) inside
> subvolume 285.
>
> Due to the way that the FS trees and subvolumes work, there's no
> global namespace structure in btrfs; that is, there's no single data
> structure that represents the entirety of the file/directory hierarchy
> in the filesystem. Instead, it's broken up into these sub-namespaces
> called subvolumes, and we only record parent/child relationships for
> each subvolume separately. The "full path" you get from "btrfs subv
> list" is reconstructed from that information in userspace(*).
>
> Hugo.
>
> (*) Here's how it does it:
>
> The userspace tool gets a list of every subvolume by looking at the FS
> tree. It uses the corresponding back-refs to get the inode that
> represents each of those FS trees inside its parent:
>
> Subvol inode in subvol
> 256 991 5
> 257 896 256
> 258 1073 257
>
> From the inode numbers, it can then recursively walk back up the
> directory path to the top of each subvolume:
>
> Subvol inode in subvol relative path
> 256 991 5 henry
> 257 896 256 edward/mary
> 258 1073 257 elizabeth
>
> From that, it can then reconstruct the full pathnames, by walking back
> up the subvolume tree:
>
> subvol 258 is elizabeth in 257
> is edward/mary/elizabeth in 256
> is henry/edward/mary/elizabeth in 5
Just one (hopefully) short question: A line in the ouput of btrfs
subvolume list like
ID 257 top level 5 path test1/test1.1
says that the subvolume with name test1.1 (the last segment of the
path) and ID 257 has the path test1/test1.1 starting at the top level
subvolume which has ID 5 ?

Thanks,
Andreas
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
 
iQIcBAEBAgAGBQJN33ezAAoJEJIcBJ3+Xkgi3egP/25y7JjnHJ9ZfQ2TF0cVWlhh
4FSHKhXlokH7E8fMcBbwP6YTB2zJioRkdWKmzoNjAvLlL8QkI7PvljAipe7YMgai
Zq+FNzN2y6qkpNBhdpJC0rnURbtD7neDdcRCDF3uatP2p+m6UghfPyTfqX31h1qc
UOp+3r+HLvlhAtKILxRaIZHidpS9ThZyN2mFHyKbyMMCoFYRXlJwL8xurPWdInbQ
sgjDmXVstsnoTcDaCsdWfUkRiLyPeiieOgCiB0X+/GdEG/gE6ICtzOf93fIeJu/B
CdGoaOSz73UIPdXstqiawhKxB83Ly68GNfoc/mrjFEml91KalGUnq/6f/344u6mB
2Ipwn1dpeC5ImwZO+VEc1HSv/GPCWyotUFzjV8NB/CcYYehX8GiNY0cSaT0NjTzs
ycUOOJUTWHTmavdT8ryDILPqSsqzMnN9NnrjJhs7EjEXSkvRxNQ4vUNOsWvCPjJl
HlooInMQ8/QTBkBLPkkiHWmhNuUaMPH6DJ85v6RNpFLiyf9TFDzBJvvyrZbkWx2y
tIvg8C1oKuZ1iulZidfY36h2wf4u/DuYgNYPSL0vsdOfABStn9MBeqPbqeF6fF42
AJ0gzVd+cqIWiFbnXEi4Zxt72l1DViLqe3Rxij2u00QOPRMtgGoKcwY7WmLKBnU5
1/vjmYvTJNnShewXMvsh
=zCSk
-----END PGP SIGNATURE-----


  reply	other threads:[~2011-05-27 10:06 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-26 21:22 strange btrfs sub list output Stephane Chazelas
2011-05-27  8:01 ` Stephane Chazelas
2011-05-27  8:21   ` Andreas Philipp
2011-05-27  8:47     ` Stephane Chazelas
2011-05-27  9:01       ` Stephane Chazelas
2011-05-27  9:12       ` Hugo Mills
2011-05-27  9:24         ` Andreas Philipp
2011-05-27  9:30         ` Stephane Chazelas
2011-05-27  9:45           ` Hugo Mills
2011-05-27 10:06             ` Andreas Philipp [this message]
2011-05-27 10:29               ` Hugo Mills
2011-05-27 11:30             ` Stephane Chazelas
2011-05-27 11:38               ` Hugo Mills
2011-05-27 11:49               ` Andreas Philipp
2011-05-31 10:00                 ` Stephane Chazelas
2011-05-31 17:40                   ` C Anthony Risinger
2011-05-31 18:50                     ` Andreas Philipp
2011-05-31 19:32                       ` C Anthony Risinger
2011-06-02  6:23                         ` C Anthony Risinger

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=4DDF77B4.4040505@gmail.com \
    --to=philipp.andreas@gmail.com \
    --cc=hugo@carfax.org.uk \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=stephane_chazelas@yahoo.fr \
    /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).