On Sat, May 22, 2021 at 08:48:14PM +0200, Jakob Unterwurzacher wrote:
> The read loop always requested 4096 bytes, which only works
> when the total read length is a multiple of 4096 bytes.
The total read length should be
"The length of this extent is (hole_off - data_off)"
according to the comments above do_extent_copy(). Total read length
being not a multiple of 4k means 'data_off' or 'hole_off' is not 4k
aligned.
>
> This is not neccessarily true, and when it's not, len wraps
But generic/286 creates source files with lenght of all data extents and
hole extents being multiple of 4k. So I still don't understand why this
is valid for gocryptfs. Shouldn't that be a bug in seek_data/seek_hole
in gocryptfs? Could you please elaborate?
Thanks,
Eryu
> around to UINT64_MAX and you get a lot of these:
>
> ERROR: [error:38] reached EOF:Success
>
> This was caught when running xfstests against gocryptfs,
> an encrypted overlay file system.
>
> On ext4, the test still passes after this change.
>
> Signed-off-by: Jakob Unterwurzacher <jakobunt@xxxxxxxxx>
> ---
> src/seek_copy_test.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/seek_copy_test.c b/src/seek_copy_test.c
> index 0c2c6a3d..28c021e2 100644
> --- a/src/seek_copy_test.c
> +++ b/src/seek_copy_test.c
> @@ -98,7 +98,7 @@ do_extent_copy(int src_fd, int dest_fd, off_t data_off, off_t hole_off)
> }
>
> while (len > 0) {
> - ssize_t nr_read = read(src_fd, buf, BUF_SIZE);
> + ssize_t nr_read = read(src_fd, buf, MIN(len, BUF_SIZE));
> if (nr_read < 0) {
> if (errno == EINTR)
> continue;
> --
> 2.31.1
