Adapt to the move of stand/geli to stand/libsa/geli.

In D15743#335115, @eric_metricspace.net wrote:

Some thoughts here:

[...]
This aside, my only comment is that I'd like to see an interface that could more easily tie in to an external key storage system, such as a KMS. I did something like this in my GELI work, and one of the precursor patches can be found here: https://reviews.freebsd.org/D12698. My EFI work always used the EFI KMS interface, and a "fake" in-memory KMS is provided for the cases where there is no genuine device. This could happen in a follow-on changeset, though.

It might be worth adding another sentence to the summary on commit, along the lines of "Setting the slice to -1 prevents a false positive when checking the cached values of which slices are geli-encrypted in biosdisk.c"

I think this looks like a good solution; I'm surprised that trying to munge just the d_offset of the original disk_devdisk while leaving the other fields untouched actually worked as well as it did for so long.

In D15844#335573, @allanjude wrote:

In D15844#335494, @ian wrote:

Do we have any idea what led to attemping to read past the end? If it happens only during tasting, that's probably because the current logic/code for tasting is a bit suspect in how it decides which sectors to try, in which case, that's what should be fixed. If it happens during normal filesystem IO then something odd is going on that we should understand better.

The rounding code is what causes the attempt to read past the end of the disk.
Since the physical disk may be 512b sectors (and in a legacy boot scenario, we can only read it in 512b sectors), but the GELI device is encrypted in 4k sectors, we round the reads up to the nearest aligned 4kb, so they can be decrypted, then return the requested portion of that to the caller.
You cannot decrypt the middle 2kb of a GELI block, hence the rounding. However, if you are trying to read the last 9 sectors of a disk, rounding that up to 16 sectors, reads past the end of the disk, if, and only if, the size of the disk is not evenly divisible by 4kb.

This review was open for less than 9 hours, and was accepted by a reviewer 4 seconds after it was first opened. Seems like the very definition of pro-forma.

In D14679#308909, @markj wrote:

In D14679#308677, @rgrimes wrote:

FINALLY: I see no reason not to commit the change in this review, it simply adds the 16) error in the proper place, and has no other effects. This is needed to prevent the error from being ignored. If you agree could you check off on the review,
Thanks.

The change has no effect unless fsck_y_enable is set, in which case we perform a potentially destructive operation (fsck -y) in a situation where fsck -p probably suffices. I don't object to it, but don't see the value in it either.

2. Running fsck -y is a last-ditch effort to recover a filesystem and IMO should never be done automatically, so not sure why that is even an option.

I tried to discourage it when it went in, but was unsuccessful.

In D14679#308435, @rgrimes wrote:

[...]

I'll support any knobs you want to add to get to your goal, just please do not remove or change any knobs that prevent me from getting to my goal.

In D14679#308384, @markj wrote:

Ian reported in the thread that -R has no effect if -p is specified, but I'm not seeing how that's true (and that behaviour doesn't really make sense if it is true).