Hello, Pascal Hambourg <pascal@plouf.fr.eu.org> writes: > On 18/05/2025 at 00:23, Nicholas D Steeves wrote: >> Pascal Hambourg <pascal@plouf.fr.eu.org> writes: >> >>> Mount option descriptions should be added as >>> partman-basicfilesystems/text/<option> debconf templates, so that they >>> can be translated. FWIW, `noatime` and `nodiratime` already have >>> description templates. >> >> Do you mean >> partman-basicfilesystems/debian/partman-basicfilesystems.templates which >> has this: >> >> Template: partman-basicfilesystems/text/noatime >> Type: text >> # :sl2: >> # Note to translators: Please keep your translations of this string below >> # a 65 columns limit (which means 65 characters in single-byte languages) >> _Description: noatime - do not update inode access times at each access >> >> ? > > Yes. > >> I didn't think that was correct, because this looks like the translation >> template that generates the po files (and mount option annotations) for >> `partman-basicfilesystems` and not for partman-btrfs. > > Currently mount options descriptions for all filesystems are defined in > partman-basicfilesystem templates. Btrfs-specific mount option > descriptions could be added to partman-btrfs templates, but then it > could be troublesome if such option is later implemented in another > filesystem. > >> It would be best if partman-btrfs can override partman-basicfilesystems's >> definitions with a mechanism like `partman-btrfs/debian/partman-btrfs.templates`. > > I don't know how cdebconf would deal with multiple definitions of the > same item. Maybe use the first or latest definition ? In either case it > would depend on udebs installation order, so unreliable. > > Alternatively, select_mountoptions could be updated to look for > filesystem-specific descriptions first and fallback to > partman-basicfilesystems generic ones. Thank you very much for the discussion and help about D-I; It's finally starting to make sense, and I appreciate the opportunity to learn by doing with your support. Given what you've shared it seems like the best way forward is to KISS and add the templates to partman-basicfilesystems, so I've created the following (tested) draft MR: https://salsa.debian.org/installer-team/partman-basicfilesystems/-/merge_requests/10 >> The problem is that some of the basicfilesystems annotations don't make >> sense in a btrfs context. For example, "noatime", which tends to be >> essential for btrfs, because btrfs COWs the file rather than updating a >> real inode. > > IIUC btrfs(5), atime update causes COW only in specific conditions such > as snapshotted or deduplicated files. (Disclaimer: my knwoledge of btrfs > internals is very limited) Sorry, I was unclear. The morbid cases that I've run into are desktop application databases like those that modern web browsers read&write to&from at what feels like near constantly--this is already a huge challenge for a COW fs. Without noatime an aged btrfs FS on LUKS2 on old SATA SSD becomes unusable even without snapshotted or deduplicated files. Unusable=hanging desktop, hanging browser windows/frames, iostat reports <<25MiB/s throughput, and the laptop produces a lot of heat. From my experience btrfs is unusable (for day-to-day desktop/workstation use) without noatime, where with ext4 or xfs it's just a nice to have tuning. As an aside, another annoying thing about btrfs is how some of the interactivity problems only manifest after months/years of FS "aging" (upstream term). Of course, the raw throughput and IOPs of an NVMe might reduce this to a nice to have tuning for casual desktop use, but I've only read about this, and IIRC there was someone who managed to show that atimes were implicated in write amplification on btrfs when compared to normal FS. > Anyway "*atime" are generic mount options and I am not sure that d-i is > the right place to advertise such implementation details. Agreed about how d-i isn't for implementation details; however, btrfs has a couple of "gotcha" differences. Mounting other FS with '-o discard' doesn't discard backup metadata structures that are used for emergency recovery in case of corruption or unexpected loss of power. To the best of my knowledge "-o discard" doesn't reduce e2fsck's ability to effectuate repairs. No other FS now discards by default, etc. Yes, it's annoying! Kind regards, Nicholas
Attachment:
signature.asc
Description: PGP signature