On 7/30/17, Duncan <1i5t5.duncan@xxxxxxx> wrote: >>> Also, all my btrfs are raid1 or dup for checksummed redundancy >> Do you have any experience/advice/comment regarding >> dup data on ssds? > Very good question. =:^) > Limited. Most of my btrfs are raid1, with dup only used on the device- > respective /boot btrfs (of which there are four, one on each of the two > ssds that otherwise form the btrfs raid1 pairs, for each of the working > and backup copy pairs -- I can use BIOS to select any of the four to > boot), and those are all sub-GiB mixed-bg mode. Is this a military or deep space device? ;) > So all my dup experience is sub-GiB mixed-blockgroup mode. > > Within that limitation, my only btrfs problem has been that at my > initially chosen size of 256 MiB, mkfs.btrfs at least used to create an > initial data/metadata chunk of 64 MiB. Remember, this is dup mode, so > there's two of them = 128 MiB. Because there's also a system chunk, that > means the initial chunk cannot be balanced even with an entirely empty > filesystem, because there's not enough space to write a second 64 MiB > chunk duped to 128 MiB. For /boot, I've also tried dup data. But because of combinations of constraints you've mentioned, I totally give-up trying to have a bullet proof /boot as my poor laptop is not mission critical as your device and as I do always have bootable backups and always carry some bootable sdcards. Perhaps that has something to do with me kicking out all systemd, inits, initramfs, mkinitcpio, dracut, etc, etc. Now the init on /boot is a "19 lines" shell script, including lines for keymap, hdparm, crytpsetup. And let's not forget this is possible by a custom kernel, its reliable buddy syslinux. Interestingly my seach for reliability started with "dup data" and ended up here. :) -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
