Reviewed-by: allanjude

Reviewed by: allanjude

Reviewed by: allanjude

Reviewed by: allanjude

Reviewed by: allanjude

Reviewed by: allanjude

In D38600#881030, @imp wrote:

btw, this looks really cool...

One other thing... where is the 'read only' flag set. I may be missing it, but I don't see it here.

In D38600#881029, @imp wrote:

so can we use zfs:<snapshot> in all the places where we can use zfs:<dataset> now with these changes?

Reviewed by: allanjude

Reviewed by: allanjude

Reviewed by: allanjude

Reviewed by: allanjude

Reviewed by: allanjude

Reviewed by: allanjude

approved by: allanjude

Approved by: allanjude

Reviewed by: allanjude

Reviewed by: allanjude

I pulled the neoverse bits out, but didn't stage it properly, and the commit went in with the bits that were supposed to be excluded

Reviewed-by: allanjude

Reviewed By: allanjude

Reviewed-by: allanjude

Reviewed by: allanjude

Reviewed by: allanjude

Reviewed by: allanjude

The reason we stopped doing this originally, is that if ZFS imports the pool using disk names like /dev/ada0p3, then the GPT label version like /dev/gpt/swap went away, and then you ended up with no swap mounted.
I don't know if things have changed somewhat since when I ran into these problems around 2015. I know there was some work to try to mitigate the issue.

Reviewed by: allanjude

Approved by: allanjude

LGTM

If you use . instead of sh thse local scripts would have more access to the environment variables.

Reviewed by: allanjude

Reviewed by: allanjude

In D36194#821718, @asomers wrote:

As far as fusefs goes, we don't know the true blocksize. The FUSE protocol gives us no way of knowing. So using f_iosize is probably the best that we can do, and that's what this patch will do.

Bu I have another question: why does ZFS always return 512B for _PC_MIN_HOLE_SIZE ? pathconf(2) operates on individual paths, so it could return VTOZ(vp)->z_blksz . But I'm not sure what that will show for an empty file; we must test it.

In D36194#821894, @mav wrote:

Looks good to me, but as was told it would be good for ZFS to report more realistic minimal hole, if possible, rather than absolute minimum. I'd also like this to be able to copy multiple blocks at a time, that may be very helpful for small blocks and sync=always.

In D36194#821698, @rmacklem wrote:

This version looks fine to me.

I do have a couple more comments....
Would allowing a greater than maxphys size for the canseek
case make sense (ie. up to 16Mbytes for ZFS instead of 1Mbyte)?

I've also updated the commit message to reflect the changes, can you give it a look over and make sure you agree with it. Thank you.

Add comment as recommended by rmacklem

Update based on feedback from rmacklem

In D36194#821555, @rmacklem wrote:

This basically looks ok to me. However, I have been recently playing with
sparse files on ZFS and I don't seem to be able to create an imbedded
hole (one not to EOF) which is less than 128K and I seem to be able to
create a hole of just about any size at EOF (truncate grows file size).

With the previous change, we don't need the condition when resetting xfer at the end of the loop

Set blksize to match xfer in the maxphys case, because vn_write_outvp() copies in blksize chunks

Fix missing ;

overcome by events

Reviewed by: allanjude