On Fri, Jul 2, 2010 at 2:38 PM, Goffredo Baroncelli <[email protected]> wrote: > On Friday, July 02, 2010, Chris Mason wrote: >> On Wed, Jun 30, 2010 at 09:26:11AM -0500, C Anthony Risinger wrote: > [...] >> > what about this: would it be possible to have TWO subvolumes by >> > "default"? the regular one (current directory, "."): >> > >> > mount -o subvol=. <btrfs_dev> /mnt >> > >> > would behave as it does now. BUT... there would then be a special, >> > permanent (like "." is right now) subvol, say "parent directory" >> > (".."): >> > >> > mount -o subvol=.. <btrfs_dev> /mnt >> > >> > TWO dots would mount the parent of ".", where i could then swap out >> > the real default ("."). >> > >> > would that work? >> >> We do provide a set-default ioctl that can be used to change the default >> for the next mount. This is pretty close to what you want, let me >> think about ways to make it easier to use. >> >> -chris > > Hello Chris, > > to me it seems that the Anthony request make sense. And it not so difficult to > have. We have all the pieces, we need only a "policy" regarding the subvolume > use and a bit of glue > It should be sufficent to "replace" the standard mkfs.btrfs command with the > following commands sequence > > # mkfs.btrfs <device> > # mount <device> /mnt/<tmp> > # btrfs subvol create /mnt/<tmp>/__root__ > # btrfs subvol set-default __root__ /mnt/<tmp>/ > # umount <device> > > So if an user don't want to care about a subvolume, he simply mount a btrfs > filesystem without any option. This user will work inside the __root__ > subvolume, where he can create snapshot, subvolume... > > Instead if an user want to play with different root in different subvolumes, > he have to mount the ".", where he can manage the root-subvolume(s) (renaming, > moving, snapshotting/branching ... ). > > The key is to think the "." subvolume only to handling the subvolumes and not > to storing files. If you don't want to use it, you can simply ignore it, > because the default is to mount the __root__ subvolume.
i don't want to comment anymore on this thread, as i feel i kind of hijacked it :-), but what Goffredo has suggested above is a great idea and would solve my default subvol problems completely. the real problem is that users are installing into the "." subvol not knowing they cannot easily manipulate the system after that. as Goffredo hinted: "The key is to think the "." subvolume only to handling the subvolumes and not to storing files." if a empty subvol is created, then marked as the new mount default, users would never know the difference, and integrators like me could still get "underneath" to prepare the system for all the cool distribution-specific btrfs features. C Anthony -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
