.@dcolascione I had a thought that woke me up from sleep, instead of A/B partitioning EFI, just make your entire disk, minus the gpt header, a bcachefs/whatever filesystem. And for setting up boot, create a single file that'll be the next EFI partition, mark it as nocow, and create the partition in the gpt header.
The bcachefs filesystem isn't reflected in the gpt table at all, it compromises the "empty space".
Also this lets you create partitions etc anything dynamically at runtime too. Make a NTFS partition file, install windows, also make a efi that boots into it & add a ui element, when clicked sets efi nextboot var to that partition. Really well contained.
5
1
32
2,995
You have to make sure the files are allocated contiguously, but sure, that'll work fine. It's, in effect, yet another kind of partition management. Have to make sure nothing stomps on the "empty" space and disk maintenance (does bcachefs have something like btrfs balance?) updates the partition table (and keeps file allocated contiguously).
1
1
280
nocow will ensure it's contiguous & unencrypted in bcachefs in the future, already the case in btrfs
bcachefs has reconcile yeah, you can expand partitions, but this system wouldn't use that part of bcachefs as it's totally bypassing gpt (though you'd still use reconcile after adding redundancy etc)
You gotta be careful about those tools, yeah. But in such a system you'd be changing so much that I don't think this would be a risk, just make people use your partition manager
2
1
267
nocow does no such thing. If I take a snapshot including a nocow file, the multiply-referenced extents become COW again. And I don't think on either FS there's a contiguity guarantee.
1
1
83
You sure? nocow is required for swap, and with a nocow file you can reuse the swap in a fresh boot after hibernation, so it has to stay in place
Kernel will refuse swapon on non-nocow files on filesystems, as it needs it to be continguent (you can mount a non continguent file as vdisk, but that beats the point of swap)
1
141
I wonder if you can take a snapshot of a swap file in btrfs then, it shouldn't be possible if the nocow-ness is in-use (?) which would also be the case for partition-files
1
135
A swap file doesn't need to be contiguous. Kernel just needs its stable extents. And btrfs just forbids snapshots of volumes with active swap files. If you swapoff, snapshot, then attempt to swapon, that'll fail too.
I think you can do your partition-as-btree-fs-file thing, but you'd need some minimal FS support to pin the physical extents and update EFI only after you've defragged down to one of the extents. You'd also have to regard the EFI reference as another reference root; easiest would be a special subvolume with one "file" per EFI partition and the FS itself managing its first block as GPT partition table. If that makes sense.
2
1
82
Last part seems less than ideal, the whole point is having the file wherever. Maybe an attr that is then interpreted by the system to make it a contiguous & gpt-header-entry would be better. I don't want to depend on the gpt header for the fs metadata at all, instead gpt should be synced to fs state, it's an external system
1
79
You can still have a file wherever, and the FS could still stick the file wherever. But FS-managed GPT table combines the 1) must-be-contiguous signal, the 2) EFI/GPT header as GC-root (so it can't dangle) signal, and 3) transactional PT updates.
Looking it up just now, ISTM GPT partition disk format is such that you can move a partition's extent from [A,B) to [C,D) *atomically*, and the btree-fs can just arrange to do this in correct order relative to its own file juggling.
1
1
80
Ahhh, fair enough, that's even better
So just a single attr on a file that has gpt partition metadata is enough. And it's a normal file in a system closure, so once the closure disappears so does the partition!
You'd have some safeguards that mandate the toplevel fs have at least 1 efi partiton-file to not shoot yourself, and you get total safety and freedom
2
1
57
