Hi Pierre-Yves, Thank you for your interest :-) Reply follows inline: Cyril, if you have time to skip to the bottom for a problem/question I'd really appreciate it. Pierre-Yves David <pierre-yves.david@octobus.net> writes: > Hi Nicolas, > > Cyril pointed to you as the person to talk to about btrfs. > Thank you for CCing debian-boot. My username is "sten" and my IRC nick is "sten0". > I am a btrfs and Debian user and there are a couple of option I would be > happy to have avaible from the installer. > > The first one is quite simple, withing the "partition management", there > is a dialog to select mount option. However, the > `user_subvol_rm_allowed` option is not available there. The option is > handy and it would be nice to have a line for it. > I think we should wait a while before doing this one and should not be encouraging user-initiated snapshots at this time. At a minimum we should have support for a /home subvolume first. If I understand btrfs correctly a malicious user can still DOS the I/O from the rootfs subvolume, similarly to a fork bomb. I'd possibly like to see a "user_subvol_mk_allowed" mount option, where the default would be "no", if finer-grained access controls don't materialise soon. > The second one is a bit trickier (but not crazy either). I usually > prefer to install my system in a dedicated subvolume (set as the default > subvolume) to allow me to easily do clean snapshot of the system content > with clean snapshot management (ie: outside of the things we > snapshot). Agreed, and also the current state of no subvolumes is too hard for many users to migrate from. At some point I should probably write up a doc, if only for users who installed to btrfs before the future point in time when we'll install to a rootfs subvolume and have fancy tools to do next-gen things. > I would be nice to have an option to specify a subvolume that should be: > > - created > - set as default subvolume for the btrfs volume This isn't necessary, because "subvol=@rootfs" can be automatically added to the mount options of the volume chosen for "/". I believe this approach is better because it's less opaque, and because it appears to better support future boot environments/bootable snapshots/system restore points. > - used by the Debian installer to install the system too (should be > trivial once the first 2 are done). > > What do you think and how should I proceed if I want to contribute this > kind of changes ? > Well, I'd like to form a btrfs task force team! You're welcome to join :-) I have an initial proof of concept MR here: https://salsa.debian.org/installer-team/partman-btrfs/-/merge_requests/1 It worked in March, but started failing in August or so, and I've had trouble finding the time to debug the debian-installer. Basically my MR just creates a non-configurable "@rootfs" subvolume and installs to that. Everything else can be done post-install. As for the big plan of making btrfs layout and features configurable in d-i: the three models that come to mind are the d-i code for mdadm, LVM, and ZFS (if still exists and has been kept up-to-date), with integration with cryptsetup. Fedora's now defaulting to installing on btrfs, so it might soon be time to work on this. Previously the problem with making btrfs volume configuration as visible as mdadm and LVM was that this would have been an arguably premature implicit endorsement for general use. Cyril, now the question: Did I miss the memo for a big d-i change that limited what partman-foo packages could do or make a mistake somewhere? For btrfs with a rootfs subvolume, the volume needs to be unmounted, and then remounted. Could this be triggering a d-i error condition? Thank you, Nicholas
Attachment:
signature.asc
Description: PGP signature