9 Oct 2024 |
emily | UDF is the DVD/BluRay filesystem, so presumably it learned from ISO 9660 | 19:10:51 |
aloisw | ISO 9660 appears to be read-only, which does not look very useful. | 19:39:25 |
aloisw | Also I just checked both my physical machine and my testing VM for UDF support, and it appears they both don't have it :( Maybe something for the future though. | 19:40:42 |
aloisw | Amusingly, the hardware appears to support NTFS, but I'm not sure how much of a good idea that is (due to possible driver quality issues both in the firmware and on Linux), and in any case it's not universally supported either. | 19:42:44 |
emily | I feel like you could do something to give FAT32 atomic writes. | 19:43:37 |
emily | like just rewrite entire files if you want to change them as a starting point. | 19:44:00 |
emily | it seems like you could at least do an A/B thing. | 19:44:48 |
emily | where you have two copies of the filesystem in the partition and twiddle the pointers in the headers to switch which one is active. | 19:45:04 |
aloisw | In reply to @emilazy:matrix.org like just rewrite entire files if you want to change them as a starting point. FAT problems go way deeper than that. Metadata operations themselves are not atomic due to complete lack of journaling, CoW or similar techniques. | 19:46:25 |
emily | right. | 19:46:46 |
emily | that's why I'm wondering if you can just do an A/B thing as a first proof of concept. | 19:46:59 |
aloisw | In reply to @emilazy:matrix.org it seems like you could at least do an A/B thing. Heh, I guess you could do A/B ESPs, corrupt something (maybe the partition type) prior to writing, and then fix it again after the write. | 19:47:55 |
emily | I was thinking something more evil where you have one partition that contains two copies of a FAT FS, and to write you synchronize the inactive half with the active one, make your changes, and then write over the BIOS pointer block or whatever to point to the other one. | 19:49:32 |
emily | ha! | 19:49:47 |
emily | https://en.wikipedia.org/wiki/Transaction-Safe_FAT_File_System | 19:49:48 |
emily |
The Transaction-Safe FAT File System (TFAT) of the TFAT12, TFAT16 and TFAT32 file systems is a driver layer modification to the original FAT file systems FAT12, FAT16 and FAT32 maintaining two copies (FAT 0 and FAT 1) of the file allocation table instead of two identical ones. While performing a drive operation, changes would be made to FAT 1. When the operation is complete, the FAT 1 table would be copied to FAT 0, updating the stable view of the file system.[1]
| 19:49:51 |
emily | looks like Microsoft stole my idea. | 19:49:56 |
aloisw | In reply to @emilazy:matrix.org I was thinking something more evil where you have one partition that contains two copies of a FAT FS, and to write you synchronize the inactive half with the active one, make your changes, and then write over the BIOS pointer block or whatever to point to the other one. Yeah but that's a different filesystem, at which point you can also implement a better one (maybe UDF). | 19:52:01 |
emily | it's different on the writing end | 19:52:13 |
emily | but existing UEFI firmware can still read it | 19:52:17 |
emily | usually the software that writes to the ESP is under your control but the firmware is not | 19:52:40 |
ElvishJerricco | that's... intriguing | 19:52:54 |
emily | also, it would still fall back relatively gracefully when unaware software modifies it, I think, as long as you can set limits on the size | 19:53:05 |
aloisw | In reply to @emilazy:matrix.org usually the software that writes to the ESP is under your control but the firmware is not I have bad news for you… sometimes the software that writes to the ESP is the firmware. | 19:54:23 |
ElvishJerricco | oh, true. | 19:54:31 |
ElvishJerricco | systemd-boot writes to it too, which of course means using the firmware's FS driver | 19:54:45 |
emily | systemd-boot could be made to use our RobustFAT™ code, though. | 19:55:02 |
emily | in theory. | 19:55:02 |
emily | when does firmware write directly to it? | 19:55:08 |
ElvishJerricco | In reply to @emilazy:matrix.org systemd-boot could be made to use our RobustFAT™ code, though. if you wanna implement a file system driver in systemd-boot; but it's designed to explicitly avoid writing FS drivers | 19:55:34 |