P.S. Yes, I also updated https://wiki.debian.org/DebianInstaller/Trixie/Wishlist :)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

I opened an MR for discussion because we were so close (and now into)
the freeze, and because I won't be able to find answers for a couple of questions in any kind of timely manner. Here are the questions; please
feel free to reply either here or at the MR:

1. Can the fstab tab mount line generating script handle both the = and :
symbols? Ie, can partman-btrfs have "compress=zstd:1" in the list of
mount options?

2. How do I actually enable/preselect a mount option by default?

3. Should we hide dangerous options like "nobarrier" by making them
exclusive to expert mode? How?

4. The tooling around transparent compression is still horrible. It's
still not possible to actually know how much free space you have, and
running out of space with btrfs usually requires temporarily adding
another device so that btrfs can create a workspace to do any required
operation--including deleting files, snapshots, etc. Should this be
hidden in expert mode?

All rationale is in both the commits and the changelog. As ever, I
prefer to insist on safe rather than featureful defaults, particularly
at this stage of the trixie cycle!

https://salsa.debian.org/installer-team/partman-btrfs/-/merge_requests/3

Regards,
Nicholas

-----BEGIN PGP SIGNATURE-----

iQJEBAEBCgAuFiEE4qYmHjkArtfNxmcIWogwR199EGEFAmgmNbYQHHN0ZW5AZGVi aWFuLm9yZwAKCRBaiDBHX30QYUdND/9F+qbUJR4+EdCKcowIBVO8G73ZlFTTdUPE H4u82h8CBTPc44Vb8RezArS3WP9zQDxpwUI1KuSBhkEVwLDOXW+x+gx+go2n+sbz kzESI5o8AzRYSBRlP4vSUfO6tdjixDUy0yzUuvhlVPiiUZIavPkZNyOV04cTP7dk 0DQNmndXhGtJRMffqzriz901Ijj2njbnlIborL/tn88J1HFb5h0u7CgIWbPKsRKA hObcKeBNa0b5WYHqdWPlhD2Oqmn5D1FJHZWqaHxwha4LPdrkVEJ3t9G2DoMwi6Sc FTHzDFgQrUOXoiJobHIbID4DhxLqrwDiQ121R/riqcdDxzj562NwXlYjYBePuXOk afU3nqrCd2WIldmcaAFeU3eAAzzq4Xa5uJ1MUJplr1XVpp9nGEVdjpsnhSbGAQ7E Wo/KEfWmlCfzqyyO0l12X44t8mBSsgpBg4xfVHZ1WraffCsC11xEelxphEderuR9 M/kSBG0e69hEL55XfNNlM05eiEyrfcULknxlSxEsK3f92uKfUvrzAKFICaiJZAh0 Rds7oPUyUUzt0/+X1JlAn7i0/jw1JzjXXyfzwcK0QxGJ/hkgBFWrjaMTnIdN9rDi C+Ni/Iq1DipNfesl8TFOCYBmxkv9J7Peq0YlQnR9xD4Bj2mHIjucqRigX37tR47W
tHc/s0LLZQ==
=af4d
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Nicholas D Steeves <sten@debian.org> writes:

1. Can the fstab tab mount line generating script handle both the = and :
symbols? Ie, can partman-btrfs have "compress=zstd:1" in the list of
mount options?

I worried for nothing, and confirmed this works fine.

-----BEGIN PGP SIGNATURE-----

iQJEBAEBCgAuFiEE4qYmHjkArtfNxmcIWogwR199EGEFAmgmnV8QHHN0ZW5AZGVi aWFuLm9yZwAKCRBaiDBHX30QYZdzD/wOluEVeEutFXjC9LgAx45vgsno5ymonsHX ijwlqUib3FIdyK2um+tIokgQ1ZTK/w6s4/P80AfobRffam5O4Bw4L6OWuYt4Yztr 7yFyFT+N1kaV/X1lV4lL9UhvKx+FbaGZ9H/sZ/rnxX9b8BYGjd7bDK76eOSMgd6Q 5uHHeG97lS8AGXm1FjI2DIOBsPNElBVX2NwxxjEy9s5DZum7oeH7Tpgs9RlYD9Du SeIRRqaFwyHvuGPWeF3rzuShL+0gKPE09ktsje0FQUPKes6Y+++8ybMMTD5ah3RN XdJMEb4dOegEeAK8ndyGX9gEavcKNm15wNgKuI0xC8GFpxPg1oxxZq5wmZVTt9/7 6C1blmiiCNFsPZk+9/t9Rh/kYY7JKy9Dp4Ng5GH0WjsuWgUKDrJywCS7dv94Y2Vu j1/9GkYjTRfa0u69ab/r3fsDTjEmLqAjsItyL8Ul004A6EMGlfVbR9YI+YNx3fMP c8CP/6RoKZPS1IIz7sUhIBgjwju4Zlao65SFAmzaZ1d3OqQjTz89u/c15djEjeTw QJnxkqGyd2ZMmxWRgG0441/EBMps8SU9/L6iefdcrhw41bvp8nZqZ1OB5g/t1Y5A nL+qMTd2+QYD3VkQTXw25W90SJv6cxW1ek80mr/PjbaWuYzfDyYJph6n0T4cdU8n
ziQfFeVD/Q==
=jpdg
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 15/05/2025 at 20:43, Nicholas D Steeves wrote:

1. Can the fstab tab mount line generating script handle both the = and :
symbols? Ie, can partman-btrfs have "compress=zstd:1" in the list of
mount options?

I do not know if cdebconf supports "=" and ":" in item names (used to
display option descriptions).

Also note that AFAIK partman does not currently support mutually
exclusive options, so "compress" and "compress=zstd:1" would be treated
as independent and non-conflicting options. Same with "discard",
"nodiscard, "discard=sync" and "discard=async".

2. How do I actually enable/preselect a mount option by default?

AFAIK partman does not currently supports this.

3. Should we hide dangerous options like "nobarrier" by making them
exclusive to expert mode? How?

AFAIK partman does not currently supports this. What about a
"(DANGEROUS!)" comment in the option description ?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Pascal

Thank you for your feedback, I sincerely appreciate it.

Pascal Hambourg <pascal@plouf.fr.eu.org> writes:

On 15/05/2025 at 20:43, Nicholas D Steeves wrote:

1. Can the fstab tab mount line generating script handle both the = and : >> symbols? Ie, can partman-btrfs have "compress=zstd:1" in the list of
mount options?

I do not know if cdebconf supports "=" and ":" in item names (used to display option descriptions).

I've since confirmed that the effect of "-o compress=zstd:1" is
correctly achieved both in the fstab and FS of the resulting
installation, but I haven't yet tested if it interacts with adding a description.

Also note that AFAIK partman does not currently support mutually
exclusive options, so "compress" and "compress=zstd:1" would be treated
as independent and non-conflicting options. Same with "discard",
"nodiscard, "discard=sync" and "discard=async".

2. How do I actually enable/preselect a mount option by default?

AFAIK partman does not currently supports this.

Thanks for confirming; I feel a little bit better about the hours of
fruitless research!

3. Should we hide dangerous options like "nobarrier" by making them
exclusive to expert mode? How?

AFAIK partman does not currently supports this. What about a
"(DANGEROUS!)" comment in the option description ?

That's a good idea. I used up all my free time working on other items
so didn't find an example syntax. Would it be

option ("Human description")
option "(Human Description)"

I'll test both as I wait to hear back from you or others.

Thank you,
Nicholas

--=-=-Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQJEBAEBCgAuFiEE4qYmHjkArtfNxmcIWogwR199EGEFAmgns6EQHHN0ZW5AZGVi aWFuLm9yZwAKCRBaiDBHX30QYQI0EACY7ySqMRUXmoxgFJwqpJcGCD6TLclg15h+ AAvG5Ut5LTWh+RygKXOx1HmdYHIxQCjNNDCVXBomlMPst+32fW8nMEXK7rWzFMix i9ScicNfBjRQ7fJAuCQN+YMjsEQ6F4UnyrqsTFphAT6xGHyTiVWJmdr2q5kKFh+O IYwdE4lx37HGnTMJqNa/aKwP/8tifvDOhectQrH3dPTeOaIyFsKfNKYJREcG/MTS GQgcyBtgmJHpkdJsgVwwaMez/IiXTVqfkGJDxd1BUSQQwH3yeGLT+M1BU6jWEVjK yDiGK9MSjqMQbjr35y3SUoeQZucqbOt1RJHW43HMsZcNA+HAHRY3xlxs88TkCqZP NKWrCao5JskBScsQgOVM5dlTs5X4tCuBflA3I6Qtj5+oB1EQEWHaqVKhlHwCZO0o UVCxcQ5rfzo7BkzxzBK0MIyLv4MxHJhFTsem+gR9zU1LvODrnqbhEs5xo9HmsHi3 Pkj42rWAipsG859L4o1cUFI6BM7Q1YgDp++PZ1SXTwWvnBedk/MdFYXEyA/Arvn8 5FhNkU6klqgCqVOHvl8x/PY8GsfMIV/hHEny7hypx/ST/DVp05tZpFdqEUFEpk+r hRrozGJIIDk7V3wNVeJ0Dwh1hLEOhJ3ckbfY+nWR6vuATuLBPKXEu6IQHJyhX/ln qyvqwNy6YQ==RAY2
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 16/05/2025 at 23:52, Nicholas D Steeves wrote:

3. Should we hide dangerous options like "nobarrier" by making them
exclusive to expert mode? How?

AFAIK partman does not currently supports this. What about a
"(DANGEROUS!)" comment in the option description ?

That's a good idea. I used up all my free time working on other items
so didn't find an example syntax. Would it be

option ("Human description")
option "(Human Description)"

I did not understand what you meant until I saw your new commits in the
MR. As you may already have observed, adding descriptions in
mountoptions/btrfs does not work. The current logic in partman-basicfilesystems/select_mountoptions considers each "word" in mountoptions/* files as a separate option, so you cannot add
descriptions here.

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Pascal Hambourg <pascal@plouf.fr.eu.org> writes:

On 16/05/2025 at 23:52, Nicholas D Steeves wrote:

3. Should we hide dangerous options like "nobarrier" by making them >>>> exclusive to expert mode? How?

AFAIK partman does not currently supports this. What about a
"(DANGEROUS!)" comment in the option description ?

That's a good idea. I used up all my free time working on other items
so didn't find an example syntax. Would it be

option ("Human description")
option "(Human Description)"

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

?

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.

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.

Will creating a `partman-btrfs/debian/partman-btrfs.templates` just work
or does partman-basicfilesystems need work to have support added? If it
needs to have support added, is implementing this for trixie a hard
NACK?

Thank you for the discussion and help,
Nicholas

--=-=-Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQJEBAEBCgAuFiEE4qYmHjkArtfNxmcIWogwR199EGEFAmgpDEwQHHN0ZW5AZGVi aWFuLm9yZwAKCRBaiDBHX30QYa+pD/sHvzSK+ecpEjZWjUJVkVKq1wPvMCkm/2FT YKlizQ6CeacBbHszF34M1cplcwcSe247HwIOArhtZLDwO0DXY/AuM1PqTaMQQgyn Wk3wcDyywvVCsRnqXUlFLIq/uuJ4zCUUDAxm7c0bpYKXrCACgZpr88SDuq0TquE7 x88ANmyEJ7cOIG/aRQzznFuannA9+yhtUypiqJAmwDSS7m/+onPLGECRzzgiB6YN kbR0Im4Sl66r/8o1uBUyzDmFFu/wMpVMZjMHDiY/kXrtTfMQX3jTT48020rm3byn vk1yVMqgNpwPX+00QCRx4gN5Nd29+c5jGE1xq2Uz6wkoZbWdoC+TdXeAadGB/BWS FYRrwIEjPQkxWyWfpiOJweJbQZeugXBwxIR/X/6CepXUjLtx4RvVPMUVDe+C4sgj oN8887sXRywrRM3ze+tXtS2/T1uybU9d8YVkjLsPBsH+9eP+SmTzG50lVgemyMqx WP6sKYd95BiACC7LRmVHYxNVSprpJ+ZGgTj7DRgZh8PZ3nj15hCZryty+epsveF8 ds/x0w9s5yTxvFvfVhWsORCb2Akk76ma+0bynquW1sOwEhTc6sdrLD7I8Xz+IHtZ 83TJj93Y3UIaFYbzFKGBN7YX5y0WeGLsDQgdGg3/R53jNB5luqm6eqOEGvKdfU2Y yMhYPlxa3w==y+zP
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

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)

Anyway "*atime" are generic mount options and I am not sure that d-i is
the right place to advertise such implementation details.

Will creating a `partman-btrfs/debian/partman-btrfs.templates` just work
or does partman-basicfilesystems need work to have support added?

As I wrote above with a caveat, btrfs-specific mount option descriptions
could be defined in partman-btrfs templates.

If it needs to have support added, is implementing this for trixie a
hard NACK?

I am not the one who can answer to this.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

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:

If it needs to have support added, is implementing this for trixie a
hard NACK?

I am not the one who can answer to this.

IMO this sounds rather experimental, and such work should happen during development cycle and not in freeze period.


Holger




--
Sent from /e/ OS on Fairphone3

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--=-=-Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQJEBAEBCgAuFiEE4qYmHjkArtfNxmcIWogwR199EGEFAmgp3IUQHHN0ZW5AZGVi aWFuLm9yZwAKCRBaiDBHX30QYZCKEADP4igDcJBV3J9pXOZi0yUkA9rubXkqLHzx zPNsMFb3P07yelGOyEOAJVjlSv9bm/uqIWcS3MACo/jzWcXdNRpS/wdapDDMpRwN MfsvZaZqguMWV9UBSGOLZgSKhtE7y2/rcdHDqQXxOQ8rb4omzBYCnJZ3XAcX2raX zEnS/DaNGosXphLy+watuC7V/tH9UKlg1GvMRBs2wvafr0RAUr/Rp2RppMg6T7q7 2nIEALCe4i5NEzo0eAJXwUzjtF4ajIDx2IjDyhvm49paX/lf3SnguKOhZsbRZZND Y0NE/UU3yRSUcGBrrVWffoIH5e23t41Uf6hi4g+sCt8j2p6a3rl4BGtuz5FA0ya4 CkOOmTpnAtPKCGiVhmmwBBFl2CbbAXhAeShd3Q3T21rhsZkqFjK6JFQ4WJdre1y0 N4SEVAW206F++gq0yXUVGj7ztMJnUEEkbDhqxEkql0P+ph2mZg4KDhM6T2pXKD3R SDbMd9nmv4ycOwy2Pgo6nCnTtcTkNQYjVTG8yZpA+8y7+Y6gYDMcsT6YaFAPhn4n 9fvq/T+n3G40WR19E7bUC89s6pcLSTTF8U9de3Rs9nHrx2grKib4e/skzZo8ERTc pPSqZQdQ4elLrHggEnj4tM17aTDjjhHtH0Tsn8+WAqEQsKJMQdUIJrUgQg65jHyf
FWplpe1oOQ=õOi
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Holger,

Holger Wansing <hwansing@mailbox.org> writes:

Hi,

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:

If it needs to have support added, is implementing this for trixie a
hard NACK?

I am not the one who can answer to this.

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?

Will creating a `partman-btrfs/debian/partman-btrfs.templates` just work
or does partman-basicfilesystems need work to have support added?

As I wrote above with a caveat, btrfs-specific mount option descriptions could be defined in partman-btrfs templates.

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).

I've added one user-requested feature (compress=lzo), and the remainder
of my work is pretty much annotated warnings for mount options that
users cargo-cult from reddit and various HOWTOs. I would also be happy
to write more involved release notes if necessary.

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! :)

Cheers,
Nicholas

--=-=-Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQJEBAEBCgAuFiEE4qYmHjkArtfNxmcIWogwR199EGEFAmgp3skQHHN0ZW5AZGVi aWFuLm9yZwAKCRBaiDBHX30QYZSMD/9OK3W0j4ALoNxoQR3+CxtAnood4oBlSegL cyHdM5JYgd6z3Ycs71yXW+Bb+NR+Neva4FMkok8YOtAnWSWlYbbT1J9tSJWW8ljX bsDHdi133hX7BvIwOZ0UWi8byfWnclUNiGqdkSwSy41dUGOmPJl7shhpDg5rvbWC ciGI36A94+ScuT+aweWhvezLVEJpVCPFz3fwIUPus4Y8ORC6mZVKL1XJDME/m4pL FuHEVo0bvcHpA05mrxBUJCZkd8MXu0BTUyKKSDJkKbuRtAwYePTWq1q7JXvboClL cOwwtLORuxMuS2AWwXK4FU9FEPNTMA+d6wSHjdINq1H5nbVLzm+Lrtqo1e9vgyAk jJvHZDTWzQ6Z1Qj/uOFycL6KHK/xtd+2gQzQ6TYhHr6Q2iLFeovfyBZLhg60GTWC kukGulRdUsrvMQZUKL4d+FVEDGapP1TrQyqdQLkq0LrDvMeQy3g3ERaGfT83Hxc9 W71NL4JM6hI/K+7NO714G/zuUEl/ZRZfdIX6tkc4awtFJpDfHPiYZwr1GRTMaX9M U/9mVHdsKQXsJF+sHhZGoTH++V4GYlNkdjcKUdEVGl1zwYzLZ/+vfeULXNm+DKwp qXh7pafaye/9SWvCGkLBttLjxJ4Qga6lxNpEITQeiDNzKSGQmDCMxOVD3gOLSqbQ kJ5lvGv8Wg==Keo/
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Holger,

Holger Wansing <hwansing@mailbox.org> writes:

Hi,

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:

If it needs to have support added, is implementing this for trixie a
hard NACK?

I am not the one who can answer to this.

IMO this sounds rather experimental, and such work should happen during development cycle and not in freeze period.

I can't tell what subject "this" is referring to. Yes, I agree that
it's too late to change the behaviour of select_mountoptions. Or do you
mean using templates in partman-btrfs? Or something else? To be clear,
I'm working to mitigate or warn about risk and not to add or enable
features.

Best,
Nicholas

-----BEGIN PGP SIGNATURE-----

iQJEBAEBCgAuFiEE4qYmHjkArtfNxmcIWogwR199EGEFAmgp6rgQHHN0ZW5AZGVi aWFuLm9yZwAKCRBaiDBHX30QYcWdD/42+zhelQ/TUNFYFl6Jb7C+Js6s/xrUB2+C 0ba3BU8q2HwI4aTrYSNlCgkYwPftfIVzoskK7eI7G1dhexmNL44pAPDf/KkHPX7T eh9md4SVV3UGPjJfaZwaJEhPKrrWWctfdqR/oBJZqvK+cfzkHAEctp1Dfs37aZYp joghwOEYXszT8+qJL8igbWzhScrNzRVZsVFhxpWk5/X9IJI2C0U+ProaA+tTLzsj nDFOgPpJKvhIj/axAUmnFOzWdJZCCJ5wq/Af4VA8lEe6OmoCx4oDJ0YGy9Kqi7Dt JmHG4nmiPQwusk2AX+el1R7kRj9/L6q82KL5t/+/tfkxCQyrllI8mkH1MrYW+z1M o9ZS7PzVElhAmbI2omFhyCZAe0OeUZ0BGU9Ccqunx7j/3tYFMlylKHx6ho5pheBK T7xBZIrZeLSvQ87nnFOOmiv6NbaWu3eK2y83sLkXxBlWwAlnW+DYkHWPBL8ih7dv h8a9UkX6xCbuhdBn0mtE0Qul67d0Fewm4qTg3aGecUgi7/Hg9b36nV6ZmmgJFdWo qhAdgWbgnEVCzNkUe1LW4UwuUbxNFNM9H5jCXlFUmbm6BfZX86msKXevQ4u8Bhdq NM781gd34pjobj5xSUIlTLDyifPOoGvQkWvGxGewNbsyNQ8lKyMyohEOAsg5Dcd5
ZuVi/3L8WQ==
=dWxE
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

Am 18. Mai 2025 15:21:12 MESZ schrieb Nicholas D Steeves <sten@debian.org>:

Hi Holger,

Holger Wansing <hwansing@mailbox.org> writes:

Hi,

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:

If it needs to have support added, is implementing this for trixie a
hard NACK?

I am not the one who can answer to this.

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

Will creating a `partman-btrfs/debian/partman-btrfs.templates` just work >>> or does partman-basicfilesystems need work to have support added?

As I wrote above with a caveat, btrfs-specific mount option descriptions
could be defined in partman-btrfs templates.

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).

I've added one user-requested feature (compress=lzo), and the remainder
of my work is pretty much annotated warnings for mount options that
users cargo-cult from reddit and various HOWTOs. I would also be happy
to write more involved release notes if necessary.

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.


Holger

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--=-=-Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQJEBAEBCgAuFiEE4qYmHjkArtfNxmcIWogwR199EGEFAmgqBlMQHHN0ZW5AZGVi aWFuLm9yZwAKCRBaiDBHX30QYRMPD/sERyOhskmDlpcuDhP8fZpl0oB3bQmxna19 C6GQTWXi6f5SE5RBM8FAhSr2NEkVDNX/PhWGs4IdWG6yZewzWp6ftARkF9NHDRt5 qsTEYYWCm6AZF1/FVD//RhkMzWbbOgFNuTGjRp1jgdP9XYNCTIFkuFq1yBaIYGmF zhARhtFy70YcKcSEzGZ9xZKM1avTofjwM4lLihhHhHwfs8HNfj+Z0YH/u1Dkfbiq 1BzgVS5nXBt13kgoH/kmxVVTBvSWXRqpx31rs+aePtvuGTL09iWCGGMGXRd6zp08 2k3WPIfuTarCKkWoUFu7I5rEit2BK5IOj5cltpfUU795GsJmv5t61eoiN8FBdRim auyTu/WdfX/93llmcn32EsovEfYoU5MvJ4gC2aX+rlKYu6ByZCz9/Rxz8Vrsb3ei l4kkabtK1xUTYwM4Lq80838NmZ7AEWk9KNW9fr9c9Npd0DWLzxNsY/f6c8H/M4sk MalkScPWAs+YNdSvtYV8/3NAFbAEkqiwbkNBInoTmugHQDoNvV6tKoMoIjgCgCVq nhFXjRB6QYb6/jvF2cBWSvZ7cJpJFBPNSPdrhnkjm6SQtw6V0aCFgm1P67DdXprF ggsW2rF8z8PIYSIpdEtm0ugdxtLkD2S576DKpsczsPrZ02I8ApvhaPqQl4NHXHCT 8DDbL3msdA==UY0l
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)