Re: Moving an entire subvol?
On Tue, Dec 02, 2014 at 08:41:35PM +0530, Shriramana Sharma wrote: That makes sense. Is there anywhere that the official SuSE recommended subvol layout is mentioned that I can refer to without having to start up an installer? https://www.suse.com/documentation/sles-12/singlehtml/book_sle_admin/book_sle_admin.html#sec.snapper.setup Directories that are Excluded from Snapshots I am now reading a SuSECon 2013 presentation by Nyers and Schnell but they are very generic about the recommendations. There are some recommended defaults that should be ok, the configuration is flexible and the user can tune the settings later according to the usage pattern (expected amount of data changes between snapshots, frequency of changes). -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Moving an entire subvol?
On Wed, Dec 03, 2014 at 08:02:31AM +0530, Shriramana Sharma wrote: On Tue, Dec 2, 2014 at 2:04 PM, Hugo Mills h...@carfax.org.uk wrote: Is that correct: what btr sub list shows as top level is indeed the parent subvolume? No, it's the top-level subvolume. (See my earlier mail about nomenclature). Parent subvolume has a number of meanings, none of which should be the subvolume with subvolid 5. Um I searched my inbox but didn't find a specific definition from you for top-level. You only said it's better to avoid calling it root to avoid confounding it with the subvol that may be mounted at root i.e. /. It was the first line I wrote in my first reply to your thread about subvol 5 vs subvol 0. I had hoped to be both definitive and comprehensive. IIUC the top-level subvolume can only be subvolid 5 which accords with your later comment: that putting files in the top-level subvol can't do what most people want to do with it. Hence the recommended subvol management layout at [1] https://btrfs.wiki.kernel.org/index.php/SysadminGuide#Subvolumes ... which means that I am not able to understand the output of btr sub list which gives the subvolid of whichever subvol is currently the parent (as in outer nesting) subvol. Observe: $ btr sub list . ID 257 gen 10 top level 5 path test1 ID 258 gen 10 top level 5 path test2 ID 259 gen 9 top level 258 path test2/foo $ sudo mv test2/foo test1/ $ btr sub list . ID 257 gen 10 top level 5 path test1 ID 258 gen 10 top level 5 path test2 ID 259 gen 9 top level 257 path test1/foo $ So now what is the meaning of top level? Urgh. I haven't seriously looked at that piece of output in a while. That's broken, in my opinion. Here, top level means containing subvolume ID. Hugo. -- Hugo Mills | I don't like the look of it, I tell you. Well, hugo@... carfax.org.uk | stop looking at it, then. http://carfax.org.uk/ | PGP: 65E74AC0 | The Goons signature.asc Description: Digital signature
Re: Moving an entire subvol?
On Tue, Dec 02, 2014 at 08:51:40AM +0530, Shriramana Sharma wrote: On Mon, Dec 1, 2014 at 6:24 AM, Chris Murphy li...@colorremedies.com wrote: But isn't it just possible to move i.e. reparent a subvol so I can move these two under another subvol and have that as default? You can move subvolumes. OK so I just found out that just mv test1/foo test2/ where test1, test2 and foo are all subvolumes is sufficient to reparent foo to test2, if what btr sub list shows as top level is indeed the parent subvolume. Is that correct: what btr sub list shows as top level is indeed the parent subvolume? No, it's the top-level subvolume. (See my earlier mail about nomenclature). Parent subvolume has a number of meanings, none of which should be the subvolume with subvolid 5. My suggestion is subvolumes containing binaries shouldn't be located within another subvolume that ends up being mounted, that way old binaries with possible vulnerabilities aren't exposed in the normal search path. I'm not sure what you mean. Are you saying that for example /usr/bin should be: 1) a separate subvolume than / or /usr, 2) not a child subvolume of / or /usr? openSUSE uses subvol id 5 for installing the OS to, and some directories are made subvolumes such as home var and maybe usr. Therefore when subvolid 5 is snapshot, those are exempt, and have to be individually snapshot. Yes I also noticed that openSUSE creates such separate subvols, but is there any particular benefit to making it so? In the sense of allowing independent snapshotting, yes. I might want to back up / (with usr, var, and so forth) only when I do a system upgrade, but /home every night. Making /home a separate subvol gives me the ability to snapshot those two areas independently. Fedora uses subvolumes root and home by default, and fstab uses subvol=root and subvol=home to mount them at / and /home respectively. This seems similar to Ubuntu's @ and @home setup. Is there any advantage to either? That is, one model installs root to the topmost subvol and makes usr, home etc nested subvols, whereas another makes root a nested subvol under the topmost just like usr home etc, and then mounts it to /... In general it seems people (or at least distros) prefer avoiding nesting subvolumes. Is there any particular reason for this? Esp in regard to /usr etc it would seem that if they are nested within the subvol for /, then just mounting that subvol would automatically mount all nested subvolumes, right? So the extra effort needed to mount the nested subvols would not be necessary, no? Nested subvols tend to get messy in practice. It's harder to replace a higher level one, because you've got to move the lower level ones around. It's also much harder to make a send/receive backup of the subvols in their original relationships, because of the read-only requirement. Whilst the theory came first, several years of practice has shown both that nesting subvolumes is generally more awkward to manage, and that putting files in the top-level subvol can't do what most people want to do with it. Hence the recommended subvol management layout at [1]. Hugo. [1] https://btrfs.wiki.kernel.org/index.php/SysadminGuide#Subvolumes -- Hugo Mills | We teach people management skills by examining hugo@... carfax.org.uk | characters in Shakespeare. You could look at http://carfax.org.uk/ | Claudius's crisis management techniques, for PGP: 65E74AC0 | example. Richard Smith-Jones, Slings and Arrows signature.asc Description: Digital signature
Re: Moving an entire subvol?
Shriramana Sharma posted on Tue, 02 Dec 2014 08:51:40 +0530 as excerpted: On Mon, Dec 1, 2014 at 6:24 AM, Chris Murphy li...@colorremedies.com wrote: But isn't it just possible to move i.e. reparent a subvol so I can move these two under another subvol and have that as default? You can move subvolumes. OK so I just found out that just mv test1/foo test2/ where test1, test2 and foo are all subvolumes is sufficient to reparent foo to test2, if what btr sub list shows as top level is indeed the parent subvolume. Is that correct: what btr sub list shows as top level is indeed the parent subvolume? [Noting that my use-case doesn't involve subvolumes so while I've played with them a bit my direct knowledge is limited...] It should be correct, yes. Subvolumes are in many ways super-directories, so it's little surprise simply directory manipulation such as moves would do what you might expect. They just happen to be directly mountable too, and to have various btrfs-specific effects such as snapshots stopping at subvolume boundaries, usage for btrfs send/receive, etc. My suggestion is subvolumes containing binaries shouldn't be located within another subvolume that ends up being mounted, that way old binaries with possible vulnerabilities aren't exposed in the normal search path. I'm not sure what you mean. Are you saying that for example /usr/bin should be: 1) a separate subvolume than / or /usr, 2) not a child subvolume of / or /usr? What I believe he's referencing is the potential security issue if for example you have older snapshots of /usr (which would include /usr/bin and /usr/lib(64)) accessible under normal operating conditions. These snapshots would contain older versions of binaries (and libraries) that have been security-updated on the main system, but the snapshots would of course contain the still vulnerable versions. A user trying to do a root- escalation, for instance, could then access and run one of these old and vulnerable versions by specifying the full path instead of just the name, thus getting access to a known root-escalation vuln long since patched in the main path but still vulnerable in the snapshot path. If for instance the master id=5 subvolume is still the default and routinely mounted, it will have all snapshots appearing as directories somewhere beneath its mountpoint in the tree. If those snapshots contain bin or lib dirs, the above security scenario is a real possibility, since they'll be accessible in the tree. So making something other than the master id=5 subvolume the default, mounting id=5 only when doing subvolume maintenance not routinely, and making such bin/lib-containing snapshots direct children of id=5 instead of children of the / subvolume or the like, will keep the snapshots containing the possibly vulnerable bins/libs out of normal accessibility as they'll only be visible in the tree when id=5 is mounted for snapshot maintenance, etc. -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Moving an entire subvol?
On Tue, Dec 02, 2014 at 08:51:40AM +0530, Shriramana Sharma wrote: openSUSE uses subvol id 5 for installing the OS to, and some directories are made subvolumes such as home var and maybe usr. Therefore when subvolid 5 is snapshot, those are exempt, and have to be individually snapshot. Yes I also noticed that openSUSE creates such separate subvols, but is there any particular benefit to making it so? A subvolume is also a snapshotting barrier, so it's convenient to create subvolumes in well-known paths that contain data that should not be rolled back (/var/log, /srv, bootloader). -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Moving an entire subvol?
On Tue, Dec 2, 2014 at 6:58 PM, David Sterba dste...@suse.cz wrote: A subvolume is also a snapshotting barrier, so it's convenient to create subvolumes in well-known paths that contain data that should not be rolled back (/var/log, /srv, bootloader). Hi David -- a real honour to meet one of the core Btrfs/SuSE (heh, when that was the spelling!) guys! That makes sense. Is there anywhere that the official SuSE recommended subvol layout is mentioned that I can refer to without having to start up an installer? (I currently chose ext4 for / for other reasons so I can't refer to my layout.) I am now reading a SuSECon 2013 presentation by Nyers and Schnell but they are very generic about the recommendations. -- Shriramana Sharma ஶ்ரீரமணஶர்மா श्रीरमणशर्मा -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Moving an entire subvol?
On 12/02/2014 07:11 AM, Shriramana Sharma wrote:
On Tue, Dec 2, 2014 at 6:58 PM, David Sterba dste...@suse.cz wrote:
A subvolume is also a snapshotting barrier, so it's convenient to create
subvolumes in well-known paths that contain data that should not be
rolled back (/var/log, /srv, bootloader).
That makes sense. Is there anywhere that the official SuSE
recommended subvol layout is mentioned that I can refer to without
having to start up an installer? (I currently chose ext4 for / for
other reasons so I can't refer to my layout.)
There are lots of ways to arrange your system
My preference is to create the snapshots in a super-volume outside of
the normally mounted hierarchy. This simplifies the normal operation of
tools like locate which don't understand that the duplicate files from
the snapshot are not interesting. It also means that live operations
(e.g. anything using find) naturally will not traverse the snapshots
unless the supervolume is mounted explicitly.
I typically call the active root of the system /__System and set it as
the default subvolume to make booting easier.
As in...
mkfs.btrfs /dev/whatever
mount /dev/whatever /mnt
btrfs sub create /mnt/__System
btrfs sub create /mnt/__System/home
btrfs sub set-default (number) /mnt
umount /mnt
mount /mnt
(create OS layout in /mnt)
Then when the snapshotting goes on...
mount -o subvol=/ /dev/whatever /maintenance
SUFFIX=$(date +_BACKUP_%Y-%M-%d)
cd /maintenance
btrfs sub snap -r __System __System${SUFFIX}
btrfs sub snap -r __System/home __System_home${SIFFIX}
# etc
cd /
umount /maintenance
---
The Real Way™ to think about your active subvolume layouts is to think
about what you really need to preserve and how often.
/home is an obvious candidate for frequent snapshots as it is the place
individual users are most likely to mess up, and it has the most
irreplaceable data.
/ (e.g. the semantic system root) [in my example /__System] [not
counting its various subvolumes really only needs backing up before
system software modifications via apt/yumm/portage/wahtever your distro
uses. Or right before you start doing aything tricky in /etc
/etc might rate its own subvolume if you are a tinker or your
system-wide configuration needs a lot of motility.
/var tends to have per system configuration stuff
But the real question is how much complexity of maintenance does the
system _really_ need, and how much of it are you _really_ going to maintain.
The desire to use a feature just 'cause it's there should be resisted.
If you are not going to be using the snapshots feature. If you are just
dropping the box in and you are going to ignore it, then don't subvolume
it at all.
You are looking for a balance between the theoretical ideal and the
practical outcome. If you don't know exactly why you are putting the
subvolume in place then it will likely just end up annoying you without
giving any value.
Same for taking and positioning the snapshots.
This is a corollary of the rule that states A backup script that you've
never done a restore from, should be assumed to be an _unsafe_ or
complete backup, or no backup at all.
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Moving an entire subvol?
On 2014-12-02 10:11, Shriramana Sharma wrote: On Tue, Dec 2, 2014 at 6:58 PM, David Sterba dste...@suse.cz wrote: A subvolume is also a snapshotting barrier, so it's convenient to create subvolumes in well-known paths that contain data that should not be rolled back (/var/log, /srv, bootloader). Hi David -- a real honour to meet one of the core Btrfs/SuSE (heh, when that was the spelling!) guys! That makes sense. Is there anywhere that the official SuSE recommended subvol layout is mentioned that I can refer to without having to start up an installer? (I currently chose ext4 for / for other reasons so I can't refer to my layout.) I am now reading a SuSECon 2013 presentation by Nyers and Schnell but they are very generic about the recommendations. Here's my approach to things: In the top level of the btrfs filesystem I use for /, I have a subvolume called /root, This is what get's mount on /. I also have a separate subvolume called /home for the home directories when I have those on the same FS. I place /boot on an entirely separate filesystem because I use a bunch of mount options there that would break or slow down other filesystems (most notably, noexec, nosuid, nodev, and sync). Within both /home and /root, I use a handful of subvolumes to control what gets saved in a snapshot, the most notable examples being /var//log, /usr/portage, and /home/austin/dropbox. As far as snapshots go, I take a snapshot of /root every time I boot, and keep the past 2 days worth, take a snapshot of /home hourly, and keep a weeks worth, and do a snapshot of both when I generate a system backup. I generally don't do snapshots of /boot, as I keep around the previous few kernel versions anyway, and mark things there as immutable so that I can't accidentally mess them up. smime.p7s Description: S/MIME Cryptographic Signature
Re: Moving an entire subvol?
On Tue, Dec 2, 2014 at 2:04 PM, Hugo Mills h...@carfax.org.uk wrote: Is that correct: what btr sub list shows as top level is indeed the parent subvolume? No, it's the top-level subvolume. (See my earlier mail about nomenclature). Parent subvolume has a number of meanings, none of which should be the subvolume with subvolid 5. Um I searched my inbox but didn't find a specific definition from you for top-level. You only said it's better to avoid calling it root to avoid confounding it with the subvol that may be mounted at root i.e. /. IIUC the top-level subvolume can only be subvolid 5 which accords with your later comment: that putting files in the top-level subvol can't do what most people want to do with it. Hence the recommended subvol management layout at [1] https://btrfs.wiki.kernel.org/index.php/SysadminGuide#Subvolumes ... which means that I am not able to understand the output of btr sub list which gives the subvolid of whichever subvol is currently the parent (as in outer nesting) subvol. Observe: $ btr sub list . ID 257 gen 10 top level 5 path test1 ID 258 gen 10 top level 5 path test2 ID 259 gen 9 top level 258 path test2/foo $ sudo mv test2/foo test1/ $ btr sub list . ID 257 gen 10 top level 5 path test1 ID 258 gen 10 top level 5 path test2 ID 259 gen 9 top level 257 path test1/foo $ So now what is the meaning of top level? -- Shriramana Sharma ஶ்ரீரமணஶர்மா श्रीरमणशर्मा -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Moving an entire subvol?
On Wed, Dec 3, 2014 at 2:43 AM, Austin S Hemmelgarn ahferro...@gmail.com wrote: Here's my approach to things: Wow, thanks a lot people! I'm really benefiting from your experience here. -- Shriramana Sharma ஶ்ரீரமணஶர்மா श्रीरमणशर्मा
Re: Moving an entire subvol?
On Mon, Dec 1, 2014 at 6:24 AM, Chris Murphy li...@colorremedies.com wrote: But isn't it just possible to move i.e. reparent a subvol so I can move these two under another subvol and have that as default? You can move subvolumes. OK so I just found out that just mv test1/foo test2/ where test1, test2 and foo are all subvolumes is sufficient to reparent foo to test2, if what btr sub list shows as top level is indeed the parent subvolume. Is that correct: what btr sub list shows as top level is indeed the parent subvolume? My suggestion is subvolumes containing binaries shouldn't be located within another subvolume that ends up being mounted, that way old binaries with possible vulnerabilities aren't exposed in the normal search path. I'm not sure what you mean. Are you saying that for example /usr/bin should be: 1) a separate subvolume than / or /usr, 2) not a child subvolume of / or /usr? openSUSE uses subvol id 5 for installing the OS to, and some directories are made subvolumes such as home var and maybe usr. Therefore when subvolid 5 is snapshot, those are exempt, and have to be individually snapshot. Yes I also noticed that openSUSE creates such separate subvols, but is there any particular benefit to making it so? Fedora uses subvolumes root and home by default, and fstab uses subvol=root and subvol=home to mount them at / and /home respectively. This seems similar to Ubuntu's @ and @home setup. Is there any advantage to either? That is, one model installs root to the topmost subvol and makes usr, home etc nested subvols, whereas another makes root a nested subvol under the topmost just like usr home etc, and then mounts it to /... In general it seems people (or at least distros) prefer avoiding nesting subvolumes. Is there any particular reason for this? Esp in regard to /usr etc it would seem that if they are nested within the subvol for /, then just mounting that subvol would automatically mount all nested subvolumes, right? So the extra effort needed to mount the nested subvols would not be necessary, no? Shriramana. -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Moving an entire subvol?
On Sun, Nov 30, 2014 at 9:51 AM, Marc MERLIN m...@merlins.org wrote: So the Ubuntu Wiki BtrFS entry advises against using subvol set-default because it boots its kernel using root=subvol=@ and home as subvol=@home, and these two subvols are only present under the subvol with ID 5. But isn't it just possible to move i.e. reparent a subvol so I can move these two under another subvol and have that as default? Make a new subvolume called /root and just mount subvol=root Sorry if my question wasn't clear: I wanted to know how to move a subvol to appear under another subvol other than its original parent. Turns out that sudo mv @ @home target/ is quite sufficient. If so why would the Ubuntu wiki require that set-default not be used? Just @ @home need to be moved to the new place, no? Note that you can't mount subvols recursively in one mount AFAIK. I'm not sure what you mean. I have a few subvols in my external HDD which is entirely formatted as BtrFS and if I just mount the external HDD /dev/sdc1 I am able to access all the subvols' contents as well. -- Shriramana Sharma ஶ்ரீரமணஶர்மா श्रीरमणशर्मा -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Moving an entire subvol?
On Sun, Nov 30, 2014 at 03:57:06PM +0530, Shriramana Sharma wrote: On Sun, Nov 30, 2014 at 9:51 AM, Marc MERLIN m...@merlins.org wrote: So the Ubuntu Wiki BtrFS entry advises against using subvol set-default because it boots its kernel using root=subvol=@ and home as subvol=@home, and these two subvols are only present under the subvol with ID 5. But isn't it just possible to move i.e. reparent a subvol so I can move these two under another subvol and have that as default? Make a new subvolume called /root and just mount subvol=root Sorry if my question wasn't clear: I wanted to know how to move a subvol to appear under another subvol other than its original parent. Turns out that sudo mv @ @home target/ is quite sufficient. If so why would the Ubuntu wiki require that set-default not be used? Just @ @home need to be moved to the new place, no? I've never done that. If I had to move them, I'd just change the mountpoint. Note that you can't mount subvols recursively in one mount AFAIK. I'm not sure what you mean. I have a few subvols in my external HDD which is entirely formatted as BtrFS and if I just mount the external HDD /dev/sdc1 I am able to access all the subvols' contents as well. Yes, if you mount the root, it works of course. If you mount a subvol, you cannot have it automatically have it mount other subvols. Subvols don't really know or care where they are mounted compared to one another, and who is under whom. It's just mount setup. Marc -- A mouse is a device used to point at the xterm you want to type in - A.S.R. Microsoft is to operating systems what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | PGP 1024R/763BE901 -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Moving an entire subvol?
On Sat, Nov 29, 2014 at 8:31 PM, Shriramana Sharma samj...@gmail.com wrote: So the Ubuntu Wiki BtrFS entry advises against using subvol set-default because it boots its kernel using root=subvol=@ and home as subvol=@home, and these two subvols are only present under the subvol with ID 5. The advice may have had to do with GRUB behavior prior to 2.02. Previously GRUB attempted to honor the btrfs default subvolume, and therefore treated any path in grub.cfg relative to the default subvolume. Now, GRUB behaves the same as the subvol= mount option, it is always treated as an absolute path from subvol id 5, hence the default subvolume is ignored. Since the default subvolume is set by a user space program I think it's a domain violation for anything to subvert this; it really should remain a shortcut for the user's benefit only, so they can use mount without -o subvol=. Everything else should explicitly pass subvol= But isn't it just possible to move i.e. reparent a subvol so I can move these two under another subvol and have that as default? You can move subvolumes. My suggestion is subvolumes containing binaries shouldn't be located within another subvolume that ends up being mounted, that way old binaries with possible vulnerabilities aren't exposed in the normal search path. Possibly this is a hypothetical question as I'm not sure whether it would be actually practically required but looking at the specific Ubuntu advice on this I thought I should ask. I'm also not sure what openSUSE (or other distros) do about this... Do they mount root using subvolid, or subvol name or such? openSUSE uses subvol id 5 for installing the OS to, and some directories are made subvolumes such as home var and maybe usr. Therefore when subvolid 5 is snapshot, those are exempt, and have to be individually snapshot. The snapshots are found in the same root directory everything else is, in a . directory (I think .snapshots ?) Fedora uses subvolumes root and home by default, and fstab uses subvol=root and subvol=home to mount them at / and /home respectively. I don't know any distro using subvolid right now but that might be prudent as it's far less user domain than subvolume names. -- Chris Murphy -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Moving an entire subvol?
So the Ubuntu Wiki BtrFS entry advises against using subvol set-default because it boots its kernel using root=subvol=@ and home as subvol=@home, and these two subvols are only present under the subvol with ID 5. But isn't it just possible to move i.e. reparent a subvol so I can move these two under another subvol and have that as default? Possibly this is a hypothetical question as I'm not sure whether it would be actually practically required but looking at the specific Ubuntu advice on this I thought I should ask. I'm also not sure what openSUSE (or other distros) do about this... Do they mount root using subvolid, or subvol name or such? -- Shriramana Sharma ஶ்ரீரமணஶர்மா श्रीरमणशर्मा -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Moving an entire subvol?
On Sun, Nov 30, 2014 at 09:01:42AM +0530, Shriramana Sharma wrote: So the Ubuntu Wiki BtrFS entry advises against using subvol set-default because it boots its kernel using root=subvol=@ and home as subvol=@home, and these two subvols are only present under the subvol with ID 5. But isn't it just possible to move i.e. reparent a subvol so I can move these two under another subvol and have that as default? Make a new subvolume called /root and just mount subvol=root Note that you can't mount subvols recursively in one mount AFAIK. This is what my system looks like: LABEL=btrfs_pool1 / btrfs subvol=root,defaults,compress=lzo,discard,skip_balance,noatime 0 0 LABEL=btrfs_pool1 /usrbtrfs subvol=usr,defaults,compress=lzo,discard,skip_balance,noatime 0 0 LABEL=btrfs_pool1 /varbtrfs subvol=var,defaults,compress=lzo,discard,skip_balance,noatime 0 0 LABEL=btrfs_pool1 /home btrfs subvol=home,defaults,compress=lzo,discard,skip_balance,noatime 0 0 LABEL=btrfs_pool1 /tmpbtrfs subvol=tmp,defaults,compress=lzo,discard,skip_balance,noatime,noexec 0 0 LABEL=btrfs_pool1 /mnt/btrfs_pool1 btrfs defaults,compress=lzo,discard,skip_balance,noatime,subvolid=0 0 0 Hope this helps. Marc -- A mouse is a device used to point at the xterm you want to type in - A.S.R. Microsoft is to operating systems what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | PGP 1024R/763BE901 -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
