Retire .write/.read file operations

[tuxoko]

The .write/.read file operations callbacks can be retired since
support for .read_iter/.write_iter and .aio_read/.aio_write has
been added. The vfs_write()/vfs_read() entry functions will
select the correct interface for the kernel. This is desirable
because all VFS write/read operations now rely on common code.

This change also add the generic write checks to make sure that
ulimits are enforced correctly on write. A similar check was
added to zpl_fallocate() so the truncate case is also handled
properly.

Signed-off-by: Brian Behlendorf [email protected]
Signed-off-by: Chunwei Chen [email protected]
Issue #5587

[mention-bot]

@tuxoko, thanks for your PR! By analyzing the history of the files in this pull request, we identified @dweeezil, @dechamps and @chenhaiq to be potential reviewers.

[behlendorf]

@tuxoko thank you for picking this one up for me. I'll give it another review.

[tuxoko]

One thing that bothers me is that the generic_write_checks should be in the same lock region as the write operations. So to ensure no time of check to use race, ideally the check needs to happen in zfs_write layer.

[behlendorf]

Functionally it looks good, we'll see what the testing says. You'll want to resubmit this to get a clean testing run with a fixed runfile.

[behlendorf]

Should be the following so both run.

[tests/functional/large_files]
tests = ['large_files_001_pos', 'large_files_002_pos']

[behlendorf]

generic_write_checks should be in the same lock region as the write operations.

Specifically under the range lock to handle the concurrent append case? We don't pass the pos variable updated from generic_write_checks() down to zfs_write() so I believe the worst that could happen is we overrun the rlimit by a few system calls. That's not ideal, but it's probably OK in practice since it would be painful to push this check down farther. Or are you concerned about a different check?

[tuxoko]

@behlendorf Yes, that's what I was talking about.

[behlendorf]

Adding a comment describing this potential issues for our future selves wouldn't be a terrible idea.

[tuxoko]

OK, also the check in fallocate seems to be wrong. We never grow size with fallocate anyway.

[behlendorf]

@tuxoko wrong or just unnecessary? Since we currently only allow hole punching I agree that case can't currently happen, but if/when we do it'll be needed.

[tuxoko]

@behlendorf
It's wrong, because we only support hole punching and hole punching implies keep size. So size is never changed and the call should not fail because of a large len.

[behlendorf]

Yes, I see. OK, let's drop that hunk from the patch.