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
--
=== Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk ===
PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk
--- A linked list is still a binary tree. Just a very unbalanced ---
one. -- dragon
signature.asc
Description: Digital signature
