Bug#1016675: This is already fixed upstream

2022-08-11 Thread Alex King
Thanks for the hint. That's easier than putting backports in apt sources. I'll try it out, it sounds promising. It may be a week or three before I get to it though. Thanks, Alex On 12/08/22 08:30, Theodore Ts'o wrote: Ah! Thanks for the clarification. I wonder if adding the following to

Bug#1016675: This is already fixed upstream

2022-08-11 Thread Theodore Ts'o
On Thu, Aug 11, 2022 at 08:02:15PM +1200, Alex King wrote: > We are using Direct IO to slow mkfs and therefore lower I/O load. I'm not > aware of a way to directly ask mkfs to reduce the I/O load or work more > slowly. Using ionice at idle priority would be ideal, but we are using the > mq-deadli

Bug#1016675: This is already fixed upstream

2022-08-11 Thread Alex King
We are using Direct IO to slow mkfs and therefore lower I/O load. I'm not aware of a way to directly ask mkfs to reduce the I/O load or work more slowly. Using ionice at idle priority would be ideal, but we are using the mq-deadline scheduler rather than bfq or anything. I understand ionice

Bug#1016675: This is already fixed upstream

2022-08-10 Thread Theodore Ts'o
I'm just curious --- what is your use case for wanting to use Direct I/O in mke2fs? In general, using buffered I/O is much faster, and the historically, Direct I/O option was primarily used as a workaround for kernels (long ago) that were buggy with respect to write throttling, and userspace progr

Bug#1016675: This is already fixed upstream

2022-08-10 Thread Alex King
This was fixed upstream in commit 08cdaf3e2422a3dda1d6dd6feefb0478ab7c3991 (https://github.com/tytso/e2fsprogs/commit/f53fa5a2ac40d595908f4ae868cca2bd195c0a88) That fix is in version 1.46.3 (so this problem should not affect sid which is on 1.46.5 currently). I build a binary (of 1.46.2) wi