btrfs: browsing subvolumes
I am new to btrfs
, and confused about subvolumes, after reading the documentation and experimenting on a local system. I have a Linux Mint system with a btrfs
root partition. Mint conveniently includes a tool that helps automate regular snapshots. I can easily list the ones it has made and kept.
$ sudo btrfs subvolume list /
ID 257 gen 52540 top level 5 path @
ID 258 gen 52540 top level 5 path @home
ID 283 gen 52467 top level 5 path timeshift-btrfs/snapshots/2019-01-15_02-00-51/@
ID 286 gen 50026 top level 5 path timeshift-btrfs/snapshots/2019-01-16_02-00-01/@
ID 288 gen 50026 top level 5 path timeshift-btrfs/snapshots/2019-01-17_02-00-01/@
ID 289 gen 50026 top level 5 path timeshift-btrfs/snapshots/2019-01-18_02-00-01/@
ID 291 gen 50409 top level 5 path timeshift-btrfs/snapshots/2019-01-19_02-00-01/@
Based on the documentation, however, I understand that snapshots can be browsed, their full tree exposed just as the main file tree, appearing as directories to the application. I could, for example, copy a single file from the snapshot to the mounted top-level volume. That is, from an application perspective, making a snapshot is much like an atomic, recursive copy.
However, I am able to find none of the seven subvolumes listed above in the contents either of /
or /home
, and no entry called timeshift-btrfs
appears in the listing of /home
.
What am I misunderstanding? Is there any directory listing that shows the tree of the snapshots?
linux btrfs
add a comment |
I am new to btrfs
, and confused about subvolumes, after reading the documentation and experimenting on a local system. I have a Linux Mint system with a btrfs
root partition. Mint conveniently includes a tool that helps automate regular snapshots. I can easily list the ones it has made and kept.
$ sudo btrfs subvolume list /
ID 257 gen 52540 top level 5 path @
ID 258 gen 52540 top level 5 path @home
ID 283 gen 52467 top level 5 path timeshift-btrfs/snapshots/2019-01-15_02-00-51/@
ID 286 gen 50026 top level 5 path timeshift-btrfs/snapshots/2019-01-16_02-00-01/@
ID 288 gen 50026 top level 5 path timeshift-btrfs/snapshots/2019-01-17_02-00-01/@
ID 289 gen 50026 top level 5 path timeshift-btrfs/snapshots/2019-01-18_02-00-01/@
ID 291 gen 50409 top level 5 path timeshift-btrfs/snapshots/2019-01-19_02-00-01/@
Based on the documentation, however, I understand that snapshots can be browsed, their full tree exposed just as the main file tree, appearing as directories to the application. I could, for example, copy a single file from the snapshot to the mounted top-level volume. That is, from an application perspective, making a snapshot is much like an atomic, recursive copy.
However, I am able to find none of the seven subvolumes listed above in the contents either of /
or /home
, and no entry called timeshift-btrfs
appears in the listing of /home
.
What am I misunderstanding? Is there any directory listing that shows the tree of the snapshots?
linux btrfs
add a comment |
I am new to btrfs
, and confused about subvolumes, after reading the documentation and experimenting on a local system. I have a Linux Mint system with a btrfs
root partition. Mint conveniently includes a tool that helps automate regular snapshots. I can easily list the ones it has made and kept.
$ sudo btrfs subvolume list /
ID 257 gen 52540 top level 5 path @
ID 258 gen 52540 top level 5 path @home
ID 283 gen 52467 top level 5 path timeshift-btrfs/snapshots/2019-01-15_02-00-51/@
ID 286 gen 50026 top level 5 path timeshift-btrfs/snapshots/2019-01-16_02-00-01/@
ID 288 gen 50026 top level 5 path timeshift-btrfs/snapshots/2019-01-17_02-00-01/@
ID 289 gen 50026 top level 5 path timeshift-btrfs/snapshots/2019-01-18_02-00-01/@
ID 291 gen 50409 top level 5 path timeshift-btrfs/snapshots/2019-01-19_02-00-01/@
Based on the documentation, however, I understand that snapshots can be browsed, their full tree exposed just as the main file tree, appearing as directories to the application. I could, for example, copy a single file from the snapshot to the mounted top-level volume. That is, from an application perspective, making a snapshot is much like an atomic, recursive copy.
However, I am able to find none of the seven subvolumes listed above in the contents either of /
or /home
, and no entry called timeshift-btrfs
appears in the listing of /home
.
What am I misunderstanding? Is there any directory listing that shows the tree of the snapshots?
linux btrfs
I am new to btrfs
, and confused about subvolumes, after reading the documentation and experimenting on a local system. I have a Linux Mint system with a btrfs
root partition. Mint conveniently includes a tool that helps automate regular snapshots. I can easily list the ones it has made and kept.
$ sudo btrfs subvolume list /
ID 257 gen 52540 top level 5 path @
ID 258 gen 52540 top level 5 path @home
ID 283 gen 52467 top level 5 path timeshift-btrfs/snapshots/2019-01-15_02-00-51/@
ID 286 gen 50026 top level 5 path timeshift-btrfs/snapshots/2019-01-16_02-00-01/@
ID 288 gen 50026 top level 5 path timeshift-btrfs/snapshots/2019-01-17_02-00-01/@
ID 289 gen 50026 top level 5 path timeshift-btrfs/snapshots/2019-01-18_02-00-01/@
ID 291 gen 50409 top level 5 path timeshift-btrfs/snapshots/2019-01-19_02-00-01/@
Based on the documentation, however, I understand that snapshots can be browsed, their full tree exposed just as the main file tree, appearing as directories to the application. I could, for example, copy a single file from the snapshot to the mounted top-level volume. That is, from an application perspective, making a snapshot is much like an atomic, recursive copy.
However, I am able to find none of the seven subvolumes listed above in the contents either of /
or /home
, and no entry called timeshift-btrfs
appears in the listing of /home
.
What am I misunderstanding? Is there any directory listing that shows the tree of the snapshots?
linux btrfs
linux btrfs
edited Jan 20 at 8:03
epl
asked Jan 20 at 7:21
eplepl
104
104
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
Keep in mind the Btrfs directory (and subvolumes) tree on your device is conceptually different than the directory structure in the OS. The root of either one is denoted /
but they are different.
The @
subvolume is identified within the Btrfs filesystem itself as @
(or /@
) but this path is not directly available in your OS. I guess the subvolume is mounted to /
which is the root of your directory tree as seen by the OS and programs (note: mount namespaces aside).
Similarly @home
is mounted under /home
.
The output of mount
command in my Kubuntu contains (among other lines):
/dev/sda1 on / type btrfs (rw,relatime,ssd,space_cache,subvolid=1902,subvol=/@)
/dev/sda1 on /home type btrfs (rw,relatime,ssd,space_cache,subvolid=258,subvol=/@home)
So my setup is identical as yours: /@
subvolume from Btrfs tree becomes /
in the OS tree. /@home
subvolume from Btrfs tree becomes /home
in the OS tree.
But I also have an access to the entire Btrfs tree:
/dev/sda1 on /mnt/ssd type btrfs (rw,relatime,ssd,space_cache,subvolid=5,subvol=/)
This means the root (/
) of the Btrfs tree is available as /mnt/ssd
in my OS. From there I can peek into every subvolume and directory. I set this mountpoint up by myself, exactly to be able to see and manage the entire Btrfs structure. The relevant line in my /etc/fstab
is as follows:
UUID=<UUID of my /dev/sda1 here> /mnt/ssd btrfs defaults,subvol=/ 0 2
Even without the above line I could still mount the root Btrfs volume manually:
mount -o rw,relatime,ssd,space_cache,subvol=/ /dev/sda1 /mnt/ssd
The main conclusion is you should mount the root of your Btrfs filesystem somewhere, with subvol=/
option. This way you gain access to the filesystem in its entirety.
Note it's a good idea not to mount Btrfs /
as your OS /
. If such mounting was the case, you had /etc
, /bin
etc. directories directly under your Btrfs /
along with subvolumes like /timeshift-btrfs
. In your OS all these entries would appear under /
after mounting the Btrfs /
to the OS /
.
By deriving your OS's root tree from Btrfs /@
you keep it tidy. You (and/or proper tools) organize subvolumes outside Btrfs /@
, while the OS keeps the majority of its /
in Btrfs /@
. Majority, because e.g. in my case /mnt/ssd/@/proc
is just an empty directory (after Btrfs /@
is mounted as /
, the proc filesystem is available in the OS's /proc
); the same for /mnt/ssd/@/home
(after Btrfs /@
is mounted as /
, the Btrfs /@home
subvolume gets mounted at what's now the OS's /home
).
Your answer is very clear. I only wish that the tutorials were half as thorough. I did not realize that my root mount was not the top-level volume, or that listing the volumes always shows all volumes on the partition, relative to the top level. Regarding the top-level mount, does keeping it create problems for indexing services, which might try to index all the snapshots? Also, regarding the home volume, wouldn't it be more convenient to put it directly in/home
rather than mounting it from/@home
? (My understanding is that snapshots to a subvolume do not include its sub-subvolumes.)
– epl
Jan 21 at 1:30
@epl[…] indexing services, which might try to index all the snapshots?
– Possible. It's your job to set them up, so they ignore/mnt
or don't cross mountpoints. –[…] rather than mounting it from /@home?
– I snapshot@
before I runapt-get upgrade
, then the snapshot doesn't include my users' personal data. And when I snapshot@home
, it includes the users' data, not the OS itself. I think such separation it's good. It's almost like having/home
on a separate partition; still you don't have to worry you'll ever have to shrink/home
to enlarge/
(or the other way around).
– Kamil Maciorowski
Jan 21 at 5:11
Ah, but I was asking about the case when/@/home
exists as a subvolume, relative to the top level. Then root and home are separate subvolumes, but administration is simplified by not needing an additional explicit mount. (Note: In my experience home and root are tied together more closely than many care to admit, because user settings are stored in home, which are generated by applications in root and depend on the version. In the old days user settings were manually created, with a minimal option set to override the defaults, but that is a different discussion!)
– epl
Jan 21 at 9:11
@epl I believe I answered your question posted as such. The original question doesn't ask about reasons and/or rationale behind choosing the name@home
for the subvolume nor its location in Btrfs hierarchy. By asking a distinct question in comments under an answer, you're drastically reducing the set of probable answerers. Besides, comments are not for discussion anyway. Be aware of this phenomenon. If you think your new question fits the site then please ask a new question.
– Kamil Maciorowski
Jan 21 at 10:13
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "3"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f1396245%2fbtrfs-browsing-subvolumes%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
Keep in mind the Btrfs directory (and subvolumes) tree on your device is conceptually different than the directory structure in the OS. The root of either one is denoted /
but they are different.
The @
subvolume is identified within the Btrfs filesystem itself as @
(or /@
) but this path is not directly available in your OS. I guess the subvolume is mounted to /
which is the root of your directory tree as seen by the OS and programs (note: mount namespaces aside).
Similarly @home
is mounted under /home
.
The output of mount
command in my Kubuntu contains (among other lines):
/dev/sda1 on / type btrfs (rw,relatime,ssd,space_cache,subvolid=1902,subvol=/@)
/dev/sda1 on /home type btrfs (rw,relatime,ssd,space_cache,subvolid=258,subvol=/@home)
So my setup is identical as yours: /@
subvolume from Btrfs tree becomes /
in the OS tree. /@home
subvolume from Btrfs tree becomes /home
in the OS tree.
But I also have an access to the entire Btrfs tree:
/dev/sda1 on /mnt/ssd type btrfs (rw,relatime,ssd,space_cache,subvolid=5,subvol=/)
This means the root (/
) of the Btrfs tree is available as /mnt/ssd
in my OS. From there I can peek into every subvolume and directory. I set this mountpoint up by myself, exactly to be able to see and manage the entire Btrfs structure. The relevant line in my /etc/fstab
is as follows:
UUID=<UUID of my /dev/sda1 here> /mnt/ssd btrfs defaults,subvol=/ 0 2
Even without the above line I could still mount the root Btrfs volume manually:
mount -o rw,relatime,ssd,space_cache,subvol=/ /dev/sda1 /mnt/ssd
The main conclusion is you should mount the root of your Btrfs filesystem somewhere, with subvol=/
option. This way you gain access to the filesystem in its entirety.
Note it's a good idea not to mount Btrfs /
as your OS /
. If such mounting was the case, you had /etc
, /bin
etc. directories directly under your Btrfs /
along with subvolumes like /timeshift-btrfs
. In your OS all these entries would appear under /
after mounting the Btrfs /
to the OS /
.
By deriving your OS's root tree from Btrfs /@
you keep it tidy. You (and/or proper tools) organize subvolumes outside Btrfs /@
, while the OS keeps the majority of its /
in Btrfs /@
. Majority, because e.g. in my case /mnt/ssd/@/proc
is just an empty directory (after Btrfs /@
is mounted as /
, the proc filesystem is available in the OS's /proc
); the same for /mnt/ssd/@/home
(after Btrfs /@
is mounted as /
, the Btrfs /@home
subvolume gets mounted at what's now the OS's /home
).
Your answer is very clear. I only wish that the tutorials were half as thorough. I did not realize that my root mount was not the top-level volume, or that listing the volumes always shows all volumes on the partition, relative to the top level. Regarding the top-level mount, does keeping it create problems for indexing services, which might try to index all the snapshots? Also, regarding the home volume, wouldn't it be more convenient to put it directly in/home
rather than mounting it from/@home
? (My understanding is that snapshots to a subvolume do not include its sub-subvolumes.)
– epl
Jan 21 at 1:30
@epl[…] indexing services, which might try to index all the snapshots?
– Possible. It's your job to set them up, so they ignore/mnt
or don't cross mountpoints. –[…] rather than mounting it from /@home?
– I snapshot@
before I runapt-get upgrade
, then the snapshot doesn't include my users' personal data. And when I snapshot@home
, it includes the users' data, not the OS itself. I think such separation it's good. It's almost like having/home
on a separate partition; still you don't have to worry you'll ever have to shrink/home
to enlarge/
(or the other way around).
– Kamil Maciorowski
Jan 21 at 5:11
Ah, but I was asking about the case when/@/home
exists as a subvolume, relative to the top level. Then root and home are separate subvolumes, but administration is simplified by not needing an additional explicit mount. (Note: In my experience home and root are tied together more closely than many care to admit, because user settings are stored in home, which are generated by applications in root and depend on the version. In the old days user settings were manually created, with a minimal option set to override the defaults, but that is a different discussion!)
– epl
Jan 21 at 9:11
@epl I believe I answered your question posted as such. The original question doesn't ask about reasons and/or rationale behind choosing the name@home
for the subvolume nor its location in Btrfs hierarchy. By asking a distinct question in comments under an answer, you're drastically reducing the set of probable answerers. Besides, comments are not for discussion anyway. Be aware of this phenomenon. If you think your new question fits the site then please ask a new question.
– Kamil Maciorowski
Jan 21 at 10:13
add a comment |
Keep in mind the Btrfs directory (and subvolumes) tree on your device is conceptually different than the directory structure in the OS. The root of either one is denoted /
but they are different.
The @
subvolume is identified within the Btrfs filesystem itself as @
(or /@
) but this path is not directly available in your OS. I guess the subvolume is mounted to /
which is the root of your directory tree as seen by the OS and programs (note: mount namespaces aside).
Similarly @home
is mounted under /home
.
The output of mount
command in my Kubuntu contains (among other lines):
/dev/sda1 on / type btrfs (rw,relatime,ssd,space_cache,subvolid=1902,subvol=/@)
/dev/sda1 on /home type btrfs (rw,relatime,ssd,space_cache,subvolid=258,subvol=/@home)
So my setup is identical as yours: /@
subvolume from Btrfs tree becomes /
in the OS tree. /@home
subvolume from Btrfs tree becomes /home
in the OS tree.
But I also have an access to the entire Btrfs tree:
/dev/sda1 on /mnt/ssd type btrfs (rw,relatime,ssd,space_cache,subvolid=5,subvol=/)
This means the root (/
) of the Btrfs tree is available as /mnt/ssd
in my OS. From there I can peek into every subvolume and directory. I set this mountpoint up by myself, exactly to be able to see and manage the entire Btrfs structure. The relevant line in my /etc/fstab
is as follows:
UUID=<UUID of my /dev/sda1 here> /mnt/ssd btrfs defaults,subvol=/ 0 2
Even without the above line I could still mount the root Btrfs volume manually:
mount -o rw,relatime,ssd,space_cache,subvol=/ /dev/sda1 /mnt/ssd
The main conclusion is you should mount the root of your Btrfs filesystem somewhere, with subvol=/
option. This way you gain access to the filesystem in its entirety.
Note it's a good idea not to mount Btrfs /
as your OS /
. If such mounting was the case, you had /etc
, /bin
etc. directories directly under your Btrfs /
along with subvolumes like /timeshift-btrfs
. In your OS all these entries would appear under /
after mounting the Btrfs /
to the OS /
.
By deriving your OS's root tree from Btrfs /@
you keep it tidy. You (and/or proper tools) organize subvolumes outside Btrfs /@
, while the OS keeps the majority of its /
in Btrfs /@
. Majority, because e.g. in my case /mnt/ssd/@/proc
is just an empty directory (after Btrfs /@
is mounted as /
, the proc filesystem is available in the OS's /proc
); the same for /mnt/ssd/@/home
(after Btrfs /@
is mounted as /
, the Btrfs /@home
subvolume gets mounted at what's now the OS's /home
).
Your answer is very clear. I only wish that the tutorials were half as thorough. I did not realize that my root mount was not the top-level volume, or that listing the volumes always shows all volumes on the partition, relative to the top level. Regarding the top-level mount, does keeping it create problems for indexing services, which might try to index all the snapshots? Also, regarding the home volume, wouldn't it be more convenient to put it directly in/home
rather than mounting it from/@home
? (My understanding is that snapshots to a subvolume do not include its sub-subvolumes.)
– epl
Jan 21 at 1:30
@epl[…] indexing services, which might try to index all the snapshots?
– Possible. It's your job to set them up, so they ignore/mnt
or don't cross mountpoints. –[…] rather than mounting it from /@home?
– I snapshot@
before I runapt-get upgrade
, then the snapshot doesn't include my users' personal data. And when I snapshot@home
, it includes the users' data, not the OS itself. I think such separation it's good. It's almost like having/home
on a separate partition; still you don't have to worry you'll ever have to shrink/home
to enlarge/
(or the other way around).
– Kamil Maciorowski
Jan 21 at 5:11
Ah, but I was asking about the case when/@/home
exists as a subvolume, relative to the top level. Then root and home are separate subvolumes, but administration is simplified by not needing an additional explicit mount. (Note: In my experience home and root are tied together more closely than many care to admit, because user settings are stored in home, which are generated by applications in root and depend on the version. In the old days user settings were manually created, with a minimal option set to override the defaults, but that is a different discussion!)
– epl
Jan 21 at 9:11
@epl I believe I answered your question posted as such. The original question doesn't ask about reasons and/or rationale behind choosing the name@home
for the subvolume nor its location in Btrfs hierarchy. By asking a distinct question in comments under an answer, you're drastically reducing the set of probable answerers. Besides, comments are not for discussion anyway. Be aware of this phenomenon. If you think your new question fits the site then please ask a new question.
– Kamil Maciorowski
Jan 21 at 10:13
add a comment |
Keep in mind the Btrfs directory (and subvolumes) tree on your device is conceptually different than the directory structure in the OS. The root of either one is denoted /
but they are different.
The @
subvolume is identified within the Btrfs filesystem itself as @
(or /@
) but this path is not directly available in your OS. I guess the subvolume is mounted to /
which is the root of your directory tree as seen by the OS and programs (note: mount namespaces aside).
Similarly @home
is mounted under /home
.
The output of mount
command in my Kubuntu contains (among other lines):
/dev/sda1 on / type btrfs (rw,relatime,ssd,space_cache,subvolid=1902,subvol=/@)
/dev/sda1 on /home type btrfs (rw,relatime,ssd,space_cache,subvolid=258,subvol=/@home)
So my setup is identical as yours: /@
subvolume from Btrfs tree becomes /
in the OS tree. /@home
subvolume from Btrfs tree becomes /home
in the OS tree.
But I also have an access to the entire Btrfs tree:
/dev/sda1 on /mnt/ssd type btrfs (rw,relatime,ssd,space_cache,subvolid=5,subvol=/)
This means the root (/
) of the Btrfs tree is available as /mnt/ssd
in my OS. From there I can peek into every subvolume and directory. I set this mountpoint up by myself, exactly to be able to see and manage the entire Btrfs structure. The relevant line in my /etc/fstab
is as follows:
UUID=<UUID of my /dev/sda1 here> /mnt/ssd btrfs defaults,subvol=/ 0 2
Even without the above line I could still mount the root Btrfs volume manually:
mount -o rw,relatime,ssd,space_cache,subvol=/ /dev/sda1 /mnt/ssd
The main conclusion is you should mount the root of your Btrfs filesystem somewhere, with subvol=/
option. This way you gain access to the filesystem in its entirety.
Note it's a good idea not to mount Btrfs /
as your OS /
. If such mounting was the case, you had /etc
, /bin
etc. directories directly under your Btrfs /
along with subvolumes like /timeshift-btrfs
. In your OS all these entries would appear under /
after mounting the Btrfs /
to the OS /
.
By deriving your OS's root tree from Btrfs /@
you keep it tidy. You (and/or proper tools) organize subvolumes outside Btrfs /@
, while the OS keeps the majority of its /
in Btrfs /@
. Majority, because e.g. in my case /mnt/ssd/@/proc
is just an empty directory (after Btrfs /@
is mounted as /
, the proc filesystem is available in the OS's /proc
); the same for /mnt/ssd/@/home
(after Btrfs /@
is mounted as /
, the Btrfs /@home
subvolume gets mounted at what's now the OS's /home
).
Keep in mind the Btrfs directory (and subvolumes) tree on your device is conceptually different than the directory structure in the OS. The root of either one is denoted /
but they are different.
The @
subvolume is identified within the Btrfs filesystem itself as @
(or /@
) but this path is not directly available in your OS. I guess the subvolume is mounted to /
which is the root of your directory tree as seen by the OS and programs (note: mount namespaces aside).
Similarly @home
is mounted under /home
.
The output of mount
command in my Kubuntu contains (among other lines):
/dev/sda1 on / type btrfs (rw,relatime,ssd,space_cache,subvolid=1902,subvol=/@)
/dev/sda1 on /home type btrfs (rw,relatime,ssd,space_cache,subvolid=258,subvol=/@home)
So my setup is identical as yours: /@
subvolume from Btrfs tree becomes /
in the OS tree. /@home
subvolume from Btrfs tree becomes /home
in the OS tree.
But I also have an access to the entire Btrfs tree:
/dev/sda1 on /mnt/ssd type btrfs (rw,relatime,ssd,space_cache,subvolid=5,subvol=/)
This means the root (/
) of the Btrfs tree is available as /mnt/ssd
in my OS. From there I can peek into every subvolume and directory. I set this mountpoint up by myself, exactly to be able to see and manage the entire Btrfs structure. The relevant line in my /etc/fstab
is as follows:
UUID=<UUID of my /dev/sda1 here> /mnt/ssd btrfs defaults,subvol=/ 0 2
Even without the above line I could still mount the root Btrfs volume manually:
mount -o rw,relatime,ssd,space_cache,subvol=/ /dev/sda1 /mnt/ssd
The main conclusion is you should mount the root of your Btrfs filesystem somewhere, with subvol=/
option. This way you gain access to the filesystem in its entirety.
Note it's a good idea not to mount Btrfs /
as your OS /
. If such mounting was the case, you had /etc
, /bin
etc. directories directly under your Btrfs /
along with subvolumes like /timeshift-btrfs
. In your OS all these entries would appear under /
after mounting the Btrfs /
to the OS /
.
By deriving your OS's root tree from Btrfs /@
you keep it tidy. You (and/or proper tools) organize subvolumes outside Btrfs /@
, while the OS keeps the majority of its /
in Btrfs /@
. Majority, because e.g. in my case /mnt/ssd/@/proc
is just an empty directory (after Btrfs /@
is mounted as /
, the proc filesystem is available in the OS's /proc
); the same for /mnt/ssd/@/home
(after Btrfs /@
is mounted as /
, the Btrfs /@home
subvolume gets mounted at what's now the OS's /home
).
answered Jan 20 at 10:39
Kamil MaciorowskiKamil Maciorowski
26.8k155781
26.8k155781
Your answer is very clear. I only wish that the tutorials were half as thorough. I did not realize that my root mount was not the top-level volume, or that listing the volumes always shows all volumes on the partition, relative to the top level. Regarding the top-level mount, does keeping it create problems for indexing services, which might try to index all the snapshots? Also, regarding the home volume, wouldn't it be more convenient to put it directly in/home
rather than mounting it from/@home
? (My understanding is that snapshots to a subvolume do not include its sub-subvolumes.)
– epl
Jan 21 at 1:30
@epl[…] indexing services, which might try to index all the snapshots?
– Possible. It's your job to set them up, so they ignore/mnt
or don't cross mountpoints. –[…] rather than mounting it from /@home?
– I snapshot@
before I runapt-get upgrade
, then the snapshot doesn't include my users' personal data. And when I snapshot@home
, it includes the users' data, not the OS itself. I think such separation it's good. It's almost like having/home
on a separate partition; still you don't have to worry you'll ever have to shrink/home
to enlarge/
(or the other way around).
– Kamil Maciorowski
Jan 21 at 5:11
Ah, but I was asking about the case when/@/home
exists as a subvolume, relative to the top level. Then root and home are separate subvolumes, but administration is simplified by not needing an additional explicit mount. (Note: In my experience home and root are tied together more closely than many care to admit, because user settings are stored in home, which are generated by applications in root and depend on the version. In the old days user settings were manually created, with a minimal option set to override the defaults, but that is a different discussion!)
– epl
Jan 21 at 9:11
@epl I believe I answered your question posted as such. The original question doesn't ask about reasons and/or rationale behind choosing the name@home
for the subvolume nor its location in Btrfs hierarchy. By asking a distinct question in comments under an answer, you're drastically reducing the set of probable answerers. Besides, comments are not for discussion anyway. Be aware of this phenomenon. If you think your new question fits the site then please ask a new question.
– Kamil Maciorowski
Jan 21 at 10:13
add a comment |
Your answer is very clear. I only wish that the tutorials were half as thorough. I did not realize that my root mount was not the top-level volume, or that listing the volumes always shows all volumes on the partition, relative to the top level. Regarding the top-level mount, does keeping it create problems for indexing services, which might try to index all the snapshots? Also, regarding the home volume, wouldn't it be more convenient to put it directly in/home
rather than mounting it from/@home
? (My understanding is that snapshots to a subvolume do not include its sub-subvolumes.)
– epl
Jan 21 at 1:30
@epl[…] indexing services, which might try to index all the snapshots?
– Possible. It's your job to set them up, so they ignore/mnt
or don't cross mountpoints. –[…] rather than mounting it from /@home?
– I snapshot@
before I runapt-get upgrade
, then the snapshot doesn't include my users' personal data. And when I snapshot@home
, it includes the users' data, not the OS itself. I think such separation it's good. It's almost like having/home
on a separate partition; still you don't have to worry you'll ever have to shrink/home
to enlarge/
(or the other way around).
– Kamil Maciorowski
Jan 21 at 5:11
Ah, but I was asking about the case when/@/home
exists as a subvolume, relative to the top level. Then root and home are separate subvolumes, but administration is simplified by not needing an additional explicit mount. (Note: In my experience home and root are tied together more closely than many care to admit, because user settings are stored in home, which are generated by applications in root and depend on the version. In the old days user settings were manually created, with a minimal option set to override the defaults, but that is a different discussion!)
– epl
Jan 21 at 9:11
@epl I believe I answered your question posted as such. The original question doesn't ask about reasons and/or rationale behind choosing the name@home
for the subvolume nor its location in Btrfs hierarchy. By asking a distinct question in comments under an answer, you're drastically reducing the set of probable answerers. Besides, comments are not for discussion anyway. Be aware of this phenomenon. If you think your new question fits the site then please ask a new question.
– Kamil Maciorowski
Jan 21 at 10:13
Your answer is very clear. I only wish that the tutorials were half as thorough. I did not realize that my root mount was not the top-level volume, or that listing the volumes always shows all volumes on the partition, relative to the top level. Regarding the top-level mount, does keeping it create problems for indexing services, which might try to index all the snapshots? Also, regarding the home volume, wouldn't it be more convenient to put it directly in
/home
rather than mounting it from /@home
? (My understanding is that snapshots to a subvolume do not include its sub-subvolumes.)– epl
Jan 21 at 1:30
Your answer is very clear. I only wish that the tutorials were half as thorough. I did not realize that my root mount was not the top-level volume, or that listing the volumes always shows all volumes on the partition, relative to the top level. Regarding the top-level mount, does keeping it create problems for indexing services, which might try to index all the snapshots? Also, regarding the home volume, wouldn't it be more convenient to put it directly in
/home
rather than mounting it from /@home
? (My understanding is that snapshots to a subvolume do not include its sub-subvolumes.)– epl
Jan 21 at 1:30
@epl
[…] indexing services, which might try to index all the snapshots?
– Possible. It's your job to set them up, so they ignore /mnt
or don't cross mountpoints. – […] rather than mounting it from /@home?
– I snapshot @
before I run apt-get upgrade
, then the snapshot doesn't include my users' personal data. And when I snapshot @home
, it includes the users' data, not the OS itself. I think such separation it's good. It's almost like having /home
on a separate partition; still you don't have to worry you'll ever have to shrink /home
to enlarge /
(or the other way around).– Kamil Maciorowski
Jan 21 at 5:11
@epl
[…] indexing services, which might try to index all the snapshots?
– Possible. It's your job to set them up, so they ignore /mnt
or don't cross mountpoints. – […] rather than mounting it from /@home?
– I snapshot @
before I run apt-get upgrade
, then the snapshot doesn't include my users' personal data. And when I snapshot @home
, it includes the users' data, not the OS itself. I think such separation it's good. It's almost like having /home
on a separate partition; still you don't have to worry you'll ever have to shrink /home
to enlarge /
(or the other way around).– Kamil Maciorowski
Jan 21 at 5:11
Ah, but I was asking about the case when
/@/home
exists as a subvolume, relative to the top level. Then root and home are separate subvolumes, but administration is simplified by not needing an additional explicit mount. (Note: In my experience home and root are tied together more closely than many care to admit, because user settings are stored in home, which are generated by applications in root and depend on the version. In the old days user settings were manually created, with a minimal option set to override the defaults, but that is a different discussion!)– epl
Jan 21 at 9:11
Ah, but I was asking about the case when
/@/home
exists as a subvolume, relative to the top level. Then root and home are separate subvolumes, but administration is simplified by not needing an additional explicit mount. (Note: In my experience home and root are tied together more closely than many care to admit, because user settings are stored in home, which are generated by applications in root and depend on the version. In the old days user settings were manually created, with a minimal option set to override the defaults, but that is a different discussion!)– epl
Jan 21 at 9:11
@epl I believe I answered your question posted as such. The original question doesn't ask about reasons and/or rationale behind choosing the name
@home
for the subvolume nor its location in Btrfs hierarchy. By asking a distinct question in comments under an answer, you're drastically reducing the set of probable answerers. Besides, comments are not for discussion anyway. Be aware of this phenomenon. If you think your new question fits the site then please ask a new question.– Kamil Maciorowski
Jan 21 at 10:13
@epl I believe I answered your question posted as such. The original question doesn't ask about reasons and/or rationale behind choosing the name
@home
for the subvolume nor its location in Btrfs hierarchy. By asking a distinct question in comments under an answer, you're drastically reducing the set of probable answerers. Besides, comments are not for discussion anyway. Be aware of this phenomenon. If you think your new question fits the site then please ask a new question.– Kamil Maciorowski
Jan 21 at 10:13
add a comment |
Thanks for contributing an answer to Super User!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f1396245%2fbtrfs-browsing-subvolumes%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown