Imran Geriskovan posted on Sun, 11 Sep 2016 21:56:07 +0300 as excerpted: > On 9/11/16, Duncan <1i5t5.dun...@cox.net> wrote: >> Martin Steigerwald posted on Sun, 11 Sep 2016 17:32:44 +0200 as >> excerpted: >>>> What is the smallest recommended fs size for btrfs? >>>> Can we say size should be in multiples of 64MB? >>> Do you want to know the smalled *recommended* or the smallest >>> *possible* >>> size? > > In fact both. > I'm reconsidering my options for /boot
>> [Snip my detail points, leaving just the summary...] >> So of my 256 MiB btrfs mixed-mode /boot, 31+4=35 MiB is overhead, >> leaving 221 MiB for actual data and metadata. But due to dup mode >> that's halved, to 110.5 MiB usable space. > > That's quite an info.. Thanks a lot.. > > Just to note again: > Ordinary 127MB btrfs gives "Out of space" around 64MB payload. 128MB is > usable to the end. Thanks, and just to clarify for others possibly following along or googling it up later, that's single mode (as opposed to dup mode) for at least data, if in normal separate data/metadata mode, and single for the combined mixed-mode chunks if in mixed-bg mode, correct? Because if the data is dup mode as well, as it would be by default in mixed-bg mode (unless on ssd), 128 MiB should allow storing only 64 MiB (and that's not accounting for the system chunk or global reserve metadata, so it'd be less than that) data. > I'm experimenting with an extracted (and customized) initrd on /boot. > That is, /boot is a "minimal root on its own" which can switch to real > root or do other things. Kernel and modules at /boot will not support > any fs other than btrfs. (Or it may) > > It seems a minimally usable root around 10MB is possible. > And it is free of udev and systemd.. You don't specifically mention the distro, but given that gentoo's one of the only general-purpose distros that hasn't switched to systemd yet (tho it offers the choice for those who want it, and I've taken that choice here), there's a fair chance that's what you're running, as both I and Martin Steigerwald (based on earlier threads) are. FWIW, a bit more about my /boot (and kernel/initr*) layout, then, since it may be apropos... both because you're dealing with /boot, and because you might be on gentoo, as well, in which case you may find even more useful hints in the below. Of course you can set it up how you like, but this is what I've found works very well for me. =:^) 1) Since I custom-configure and build my own kernels anyway, I build monolithic, no kernel modules, and indeed, the kernel options allowing loading modules are turned off -- more secure that way since I don't load modules anyway. That simplifies a lot of stuff, including no longer needing module-init- tools or whatever installed at all. So it's not. (I negated the @system listing for it; actually I negated @system entirely and added what I actually needed to my @world via world-sets, but that's beside the point.) 2) Since a multi-device btrfs / effectively requires an initr*, I do run one, using dracut to generate it, but I don't boot it as a separate file. Instead I have the kernel configured to pull it in and append it as an initramfs to each built kernel. The idea here is that I keep tested-bootable kernels along with their tested-bootable initr*s around, so whatever I may be upgrading, kernel, dracut, the initr* itself, or some package with a binary in the initr*, I always have a fallback kernel and its attached initramfs that's tested bootable. That way, should some kernel/initr* component fail, I know I can simply pick an older/tested kernel/initramfs file, since they're a single file, and boot with it, using that boot to investigate and fix the problem with the kernel/initramfs. And I also know that once I've tested a kernel/initramfs to work, if it suddenly fails, it can't be something in the initramfs or kernel itself, as that is known to work, it must instead be some problem with the hardware or in the boot after handover to the main /. One additional detail here regarding dracut: Even if you've configured dracut to not worry about modules as you run a monolithic kernel, for some reason (bug?) it still requires (as opposed to uses if installed) rmmod for an initr* build. Why it requires rmmod but not modprobe is beyond me, but it does. So now I have a no-rmmod.patch in /etc/portage/patches/sys-kernel/dracut , and I can use dracut setup for a monolithic kernel initr*, without having to have the useless rmmod from module-init-tools around for it to pull in when I build a new initr*. 3) Due to btrfs dup-mode halving my usable space on /boot, something I should have anticipated but didn't, I have only ~110 MiB of space on / boot, and the grub2 installation eats up some of it. Of course that leaves me way less room for kernels than I expected, particularly when I had the uncompressed initr* (that the kernel build compresses and appends as an initramfs to every built kernel) stored on /boot as well. Eventually that crimped my style sufficiently that I moved the uncompressed initr* elsewhere. I ended up with it on /p, my packages/ build partition, which has the kernel sources on it too, so it'd need to be mounted to build the kernel anyway. Without the uncompressed initr* on /boot, the 256 MiB btrfs dup-mode, thus ~110 MiB usable, has been fine -- I don't find myself running out of space for new kernel builds as much any more, making it much easier to git-bisect a kernel bug, for instance. =:^) So if you're going to do an uncompressed initr* on /boot, if you're using btrfs in mixed-bg dup mode as I am, better make it 384 MiB or even 512 MiB, because 256 MiB will definitely crimp your style. If OTOH you're using single mode data, presumably because you're doing mixed-mode but only single (I still wouldn't recommend non-mixed-mode at that size), 256 MiB ends up being much more reasonable. 4) I use gpt partition tables on everything. They're far more flexible and reliable than the old MBR, and because they have a checksummed second copy at the end of the device as well, they're far easier to recover if the primary copy gets corrupted (plus with the checksumming the corruption is actually detected). In gpt, I actually setup both an EFI partition and a legacy BIOS partition. They're both very small and it increases your flexibility dramatically. As it happens, my current main system was purchased just a bit before EFI replaced BIOS, and I have grub2 installed to the legacy BIOS area and the EFI unused, but both are available should that change and I decide to use EFI booting. (I may not, it sounds like more trouble than it's worth for those building their own grub, etc, but the flexibility is there should I decide to use it.) 5) The BIOS does have a hotkey to select the boot device, however, and I keep a backup /boot installed to the other ssd (primary backup) and to the spinning rust (secondary backup), just in case. That allows me to upgrade grub without worrying about killing bootability due to a corrupted grub install. I upgrade the package, then install it to one device first, then test booting to it before trying to install to the backups. 6) In ordered to facilitate installing grub2 to the backups as well as my working /boot, /boot itself is actually a symlink. By default, it points to /bt, the mountpoint for my working /boot. That way I can tell grub2 to install to /dev/sda, and it installs grub2-core to the dedicated BIOS boot partition on that device, while installing the various other grub files to the /boot, which is pointed at the mounted /bt. When I want to install grub2 to a backup, I point the /boot symlink at /bk/bt, the back-boot mountpoint, instead. Then with the appropriate backup boot mounted, I can install grub2 to either sdb or sdc as appropriate, and again have it install both grub-core to the appropriate device's dedicated BIOS boot partition, and the various grub files to / boot, which is now pointing at /bk/bt, which is where the backup /boot for the appropriate device is mounted. Because it's far easier and easier to keep track of without getting confused, to simply switch the symlink pointer and keep the backup /boots mounting in the backup location, than it would be to switch the mountpoints themselves around. -- 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
