GNU testsuite comparison:

Skip an intermittent issue tests/misc/stdbuf (fails in this run but passes in the 'main' branch)
Skip an intermittent issue tests/timeout/timeout (fails in this run but passes in the 'main' branch)

did you look if it has an impact on performances ? thanks

@sylvestre Hello. I performed a brief test on shred using two different types of files: one smaller than the block size (1 byte), and one larger (1MB). I used hyperfine to collect information about time and deviation.

hyperfine -r 10000 './target/release/shred -v -n1 foo'

I recreated the file before each test.

On 1 byte file

• the 4K and 65K blocks show the same time
• the performance remains the same because, for any block size, the number of write calls is the same (11 calls), and each call writes exactly one block of data.

1.4 ms ± 0.3 ms - uutils shred [128 bytes]
1.4 ms ± 0.3 ms - uutils shred [512 bytes]
1.4 ms ± 0.3 ms - uutils shred [2048 bytes]
1.4 ms ± 0.3 ms - uutils shred [4096 bytes]
1.4 ms ± 0.3 ms - uutils shred [16384 bytes]
1.4 ms ± 0.3 ms - uutils shred [65536 bytes]
1.3 ms ± 0.3 ms - GNU shred

On 1MB file

• performance decreases when using smaller block sizes. 4K block works ~20% slower than 65K
• GNU shred has significantly better performance, while the uutils version is ~20% slower with a 65K block and nearly 50% slower with a 4K block

3.4 ms ± 0.5 ms - uutils shred [2048 bytes]**
2.8 ms ± 0.4 ms - uutils shred [4096 bytes]
2.4 ms ± 0.4 ms - uutils shred [16384 bytes]
2.3 ms ± 0.4 ms - uutils shred [65536 bytes]
1.9 ms ± 0.4 ms - GNU shred

It seems that with a 1MB file, we have many more write syscalls (266 for 4K blocks and 26 for 65K blocks), which leads to a noticeable slowdown.

Please let me know if more detailed measurements are needed or if different data collection methods should be used.

Thank you

I'm sure it's also possible to avoid the differences with GNU shred in another way. Instead of changing the buffer size, we could modify the number of bytes that are overwritten in do_pass. Something like

        let size = if exact { bytes_left } else { std::cmp::min(4096, BLOCK_SIZE) };

In this case, the behavior would be the same as with GNU shred, but without the slowdown caused by the extra write calls. What do you think?

Here is a PR with alignment changes, but without any modification to the block size.

I'm going to close this PR, as it results in a noticeable slowdown. Fixing the differences between the GNU and uutils versions by adjusting alignment seems to be a better approach.