Re: Pointers to mirroring partitions (w/ encryption?) help?
On 06/04/2016 03:46 AM, Andrei Borzenkov wrote: 04.06.2016 04:39, Justin Brown пишет: Here's some thoughts: Assume a CD sized (680MB) /boot Some distros carry patches for grub that allow booting from Btrfs, so no separate /boot file system is required. (Fedora does not; Ubuntu -- and therefore probably all Debians -- does.) Which grub (or which Fedora) do you mean? btrfs support is upstream since 2010. There are restrictions, in particular RAID levels support (RAID5/6 are not implemented). Good to know / be reminded of (such specifics) - thanks. perhaps a 200MB (?) sized EFI partition Way bigger than necessary. It should only be 1-2MiB, and IIRC 2MiB might be the max UEFI allows. You may want to review recent discussion on systemd regarding systemd boot (a.k.a. gummiboot) which wants to have ESP mounted as /boot. UEFI mandates support for FAT32 on ESP so max size should be whatever max size FAT32 has. ... The additional problem is most articles reference FDE (Full Disk Encryption) - but that doesn't seem to be prudent. e.g. Unencrypted /boot. So having problems finding concise links on the topics, -FDE -"Full Disk Encryption". Yeah, when it comes to FDE, you either have to make your peace with trusting the manufacturer, or you can't. If you are going to boot your system with a traditional boot loader, an unencrypted partition is mandatory. No, it is not with grub2 that supports LUKS (and geli in *BSD world). Of course initial grub image must be written outside of encrypted area and readable by firmware. Good to know. Do you have a link to a how to on such? That being said, we live in a world with UEFI Secure Boot. While your EFI parition must be unencrypted vfat, you can sign the kernels (or shims), and the UEFI can be configured to only boot signed executables, including only those signed by your own key. Some distros already provide this feature, including using keys probably already trusted by the default keystore. UEFI Secure Boot is rather orthogonal to the question of disk encryption. Perhaps, but not orthogonal to the OP question. In the end, the OP is about all this 'stuff' landing at once, the majority btrfs centric, and a call for help finding the end of the string to pull on in a linear way. e.g., as pointed out, most articles premising FDE, which is not in play per OP. The OP requesting pointers to good concise how to links. -- 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: Pointers to mirroring partitions (w/ encryption?) help?
r, an unencrypted partition is mandatory. That being said, we live in a world with UEFI Secure Boot. Another learning curve (UEFI) to swallow at the same time as all the other here. Current install is the first time it has occurred to me to try to incorporate SecureBoot, UEFI, crypt, and all such 'goodness' on a fresh (raw) install. Debian is bringing apt-secure along for the ride on me, too. While your EFI parition must be unencrypted vfat, you can sign the kernels (or shims), and the UEFI can be configured to only boot signed executables, including only those signed by your own key. Some distros already provide this feature, including using keys probably already trusted by the default keystore. mirror subvolumes (or it inherently comes along for the ride?) Yes, that is correct. Just to give some more background: the data and metadata profiles control "mirroring," and they are set at the file system level. Subvolumes live entirely within one file system, so whatever profile is set in the FS applies to subvolumes. Gotcha, thus your dup observation. However ... the question was aimed at a crypto sda3, thus containing @, and probably @home, sda4 created ... how might one kick in to (btrfs) mirror sda3 in sda4, including @ and @home. I would guess, from your comment, once one adds sda4 to the sda3 set, all that (sda3) profile applies, gets applied to sda4, and all the btrfs magic goodness ... just happens. Particularly after running balance to force all that goodness to happen at once / now, rather than upon next write. So, I could take an HD, create partitions as above (how? e.g. Set up encryption / btrfs mirror volumes), then clonezilla (?) partitions from a current machine in. Are you currently using Btrfs? If so, use Btrfs' `send` and `receive` commands. Yeah. Ick. :-) Have had better luck in the past just cloning or mounting and cp -a. Likely, my lack of experience was the issue. In any case, here, the question was pointed at a new install. > That should be lot friendlier to your SSD. (I'll take this opportunity to say that you need to consider the `discard` mount *and* `/etc/crypttab` options. Discard -- or scheduling `fstrim` -- is extremely important to maintain optimal performance of a SSD, but there are some privacy trade-offs on encrypted systems.) If not, then `cp -a` or similar will work. SSD not yet in play here, but I do take your point. I had to work through all that on the SSD I do have, so I do know to peek at such whenever an SSD come into play. Didn't know about the /etc/crypttab options, thanks for that. Heck, hadn't gotten as far as knowing there was an /etc/crypttab. - thus, I think part of my OP question is what all am I attempting to swallow in one go on a fresh install here? I get dmcrypt and uefi is involved, so I can start to break down the googling into component pieces. Thus, I think, the request for an appropriate link. Something that does it all on a fresh install in one go would be good, particularly if it identifies the major sub-topics, and has 'links to more info'. Obviously, you'll have to get your boot mechanism and file system identifiers updated in addition to `/etc/crypttab` described above. Lastly, strongly consider `autodefrag` and possibly setting some highly violatile -- but *unimportant* -- directories to `nodatacow` via purging and `chattr +C`. (I do this for ~/.cache and /var/cache.) Yep, autodefrag is in the mount options. I have a number of home systems running btrfs for some years now. Started with Kubuntu 12.04 LTS (since running hwe kernels to get later btrfs tools), and a couple of 14.04's. GB rsyncs and mondoarchives fly all about the house in cascading archives, nightly. A recent 4TB HD failure is part of the reason for the OP questions. A scrub at the time revealed many failures, and dealing with that and figuring out which files to fetch from secondary archives was a challenge. BUT, FANTASTICALLY, for the first time (pre-btrfs days), at least btrfs / something specifically identified WHICH files were botched. I wasn't left wondering what botched file will reveal itself months from now ... after the botched file had cascaded to all backups! Having been bitten, and facing a new install, thought I'd better OP. Yet not looking to put in a 2nd HD If you change your mind and decide on a backup device, or even if you just want local backup snapshots, one of the best snapshot managers is btrfs-sxbackup (no association with the FS project). Thank you for that! Thus far, keeping only the OS on / and mondoarchiving it nightly, and rsync'ing /everythingelse seems to be doing the job. Perhaps even keeping the 'after the failure' complexity level down. On Fri, Jun 3, 2016 at 3:30 PM, B. S. <bs27...@gmail.com> wrote: Hallo. I'm continuing on sinking in to btrfs, so pointers to concise help articles appreciated. I've got a couple new home systems, so perhaps it's time
Pointers to mirroring partitions (w/ encryption?) help?
Hallo. I'm continuing on sinking in to btrfs, so pointers to concise help articles appreciated. I've got a couple new home systems, so perhaps it's time to investigate encryption, and given the bit rot I've seen here, perhaps time to mirror volumes so the wonderful btrfs self-healing facilities can be taken advantage of. Problem with today's hard drives, a quick look at Canada Computer shows the smallest drives 500GB, 120GB SSDs, far more than the 20GB or so an OS needs. Yet not looking to put in a 2nd HD, either. It feels like mirroring volumes makes sense. (EFI [partitions] also seem to be sticking their fingers in here.] Assume a CD sized (680MB) /boot, and perhaps a 200MB (?) sized EFI partition, it seems to me one sets up / as usual (less complex install), then creates another partition for mirroring, later. IIUC, btrfs add device /dev/sda4 / is appropriate, then. Then running a balance seems recommended. Confusing, however, is having those (both) partitions encrypted. Seems some work is needed beforehand. But I've never done encryption. I have come across https://github.com/gebi/keyctl_keyscript, so I understand there will be gotchas to deal with - later. But not there yet, and not real sure how to start. The additional problem is most articles reference FDE (Full Disk Encryption) - but that doesn't seem to be prudent. e.g. Unencrypted /boot. So having problems finding concise links on the topics, -FDE -"Full Disk Encryption". Any good links to concise instructions on building / establishing encrypted btrfs mirror volumes? dm_crypt seems to be the basis, and not looking to add LVM, seems an unnecessary extra layer of complexity. It also feels like I could mkfs.btrfs /dev/sda3 /dev/sda4, then mirror subvolumes (or it inherently comes along for the ride?) - so my confusion level increases. Especially if encryption is added to the mix. So, I could take an HD, create partitions as above (how? e.g. Set up encryption / btrfs mirror volumes), then clonezilla (?) partitions from a current machine in. I assume mounting a live cd then cp -a from old disk partition to new disk partition won't 'just work'. (?) Article suggestions? -- 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
