Hey Holger,
Holger Wansing <hwansing@mailbox.org> writes:
> Am 18. Mai 2025 15:21:12 MESZ schrieb Nicholas D Steeves <sten@debian.org>:
>>Holger Wansing <hwansing@mailbox.org> writes:
>>> Am 18. Mai 2025 09:31:17 MESZ schrieb Pascal Hambourg <pascal@plouf.fr.eu.org>:
>>>>On 18/05/2025 at 00:23, Nicholas D Steeves wrote:
>>>
>>> IMO this sounds rather experimental, and such work should happen during development cycle and not in freeze period.
>>>
>>
>>What is the subject of "IMO this sounds rather experimental"? Are you
>>referring to the following?
>
> Sorry for bad quoting style.
> I dropped the relevant mail part sadly.
>
> That is:
> Nicholas D Steeves <sten@debian.org> wrote:
>> It would be best if partman-btrfs can override partman-basicfilesystems's
>> definitions with a mechanism like `partman-btrfs/debian/partman-btrfs.templates`.
>> 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.
>
> And the above sounds like changing the basic way of how the mount options thing
> is working. And this looks "experimental" to me.
> Just my two cents
>
Thank you, and after learning from Pascal that this would require such
changes I chose the solution to edit the partman-basicfilesystem
template directly. So yes, I agree!
>>Thus I've submitted an MR that does things in the KISS way using
>>partman-basicfilesystems. I'm also ok with this work going into a point
>>release when users of older hardware report regressions such as
>>increased power usage due to continuous TRIM (Fedora is still working on
>>this).
<snip>
>>Or are you referring to translator work? If most translators are burned
>>out and don't see the value of my proposed changes at this time then
>>I'll understand and accept this. P.S. I can try a French translation if
>>it would help! :)
>
> What about all the other languages?
> Note, that the installer is all in all translated into 78 languages.
>
> Adding new translation material at this stage is ... - I have no energy to
> repeat this over and over again.
I understand, and I've followed this list for many years. The other
alternatives I considered were 1) using D-I to preconfigure the new
default (it's not possible at this time), and 2) I also CCed the kernel
team in the hopes of reverting the kernel's new default, which is
future-facing rather than past-facing. The earliest I could have
discovered this issue was in early March.
A minimal fix for the bookworm2trixie regression is this single line:
(recommended) rely on the fstrim.timer to trim freed blocks
Is that line too much? A TLDR of the problem is that btrfs now
digresses from what all other FS do, what all other FS do in Debian, and
what Windows does. I'm trying to get ahead of the problem (as it
manifests on the old computers available to me).
Looking forward to your reply,
Nicholas
P.S. The (optional) line that explains where the new upstream default is
beneficial is:
for NVMEs that see ≥100GiB of TRIMs per week
P.P.S. Of course I took the opportunity to do a complete task rather
than a minimal fix, but I would be happy to go with either the one line
or the two line minimal fixes.
Attachment:
signature.asc
Description: PGP signature