`dd` fails on GNU test `tests/dd/no-allocate.sh` - due to beeing more efficient

[cre4ture]

I investigated what this test is doing and the reason on why this test is failing.

It tests with a strict limit on the usable virtual memory the internal behaviour of dd by setting a large (30M) block_size ("ibs", "obs" and "bs") and expects certain behaviour regarding when the memory for these block-sizes are allocated and not allocated.

This way the test can validade

1. the correct behaviour for the cases where the memory should not be allocated.
2. AND it can test cases where it expects it to be allocated by testing for unsuccessfull return code.

Now, the problem with uutils is, that it is more efficient than GNU and does not need to allocate the buffer when the test expects it to do so (for seek and skip operations). It uses io::copy(src, dst) where the dst is some dummy data sink that just ignores every write. Thus no buffer is to be allocated.
Thats why the test is red.

I successfully proved this theory by artificially allocate the memory in the expected cases. I'll link the PR to this issue.

The only remaining issue could be that dd should do only one single read per block instead of multiples. I'm not sure what the io::copy() is doing internally.

[cre4ture]

I suggest to change the test such that it always expect success and make it this way green. What do you think?

[jfinkels]

That makes sense to me. It beats the alternative: making our implementation of dd allocate just to match the implementation of coreutils.

[ChrisDryden]

I did an implementation with BufReader then came across this, my understanding is that there is a performance benefit to having that buffer and that's why the test was added? #9806

[ChrisDryden]

Doing some more research and I don't think its completely correct to say that the the no-allocate test is not correct because the current implementation is more efficient, its a capability to set the buffer size based on those parameters and there are valid use cases to why you would want to do that.

The purpose of that flag is to set the read block size and there are workflows that rely on that working

[cre4ture]

Ok, I checked your linked PR. According to the comment it states that explicit read and discard using the specified block size is more efficient. If this is true, than the statement in this issue would be wrong.
Problem is, that the test in the GNU test-suite doesn't test that behavior directly but in an easy-to-cheat around way. Which doesn't improve readability either.

One solution for this would be to improve the test suite of GNU and e.g. use some 'strace' logs to ensure that the desired behavior is there. E.g. checking if the system calls to ´read` are aligned accordingly.