[LSF/MM/BPF TOPIC] selectively cramming things onto struct bio

[LSF/MM/BPF TOPIC] selectively cramming things onto struct bio

[Darrick J. Wong]

Hi everyone,

Several months ago, there was a discussion[1] about enhancing XFS to
take a more active role in recoverying damaged blocks from a redundant
storage device when the block device doesn't signal an error but the
filesystem can tell that something is wrong.

Yes, we (XFS) would like to be able to exhaust all available storage
redundancy before we resort to rebuilding lost metadata, and we'd like
to do that without implementing our own RAID layer.

In the end, the largest stumbling block seems to be how to attach
additional instructions to struct bio.  Jens rejected the idea of adding
more pointers or more bytes to a struct bio since we'd be forcing
everyone to pay the extra memory price for a feature that in the ideal
situation will be used infrequently.

I think Martin Petersen tried to introduce separate bio pools so that we
only end up using larger bios for devices that really need it, but ran
into some difficulty with the usage model for how that would work.  (We
could, in theory, need to attach integrity data *and* retry attributes
to the same disk access).

So I propose a discussion of what exactly are the combinations of bio
attributes that are needed by block layer callers.  IIRC, the DIF/DIX
support code need to be able to attach the integrity data on its own;
whereas XFS already knows which device and which replica it would like
to try.  If the storage isn't total crap it shouldn't need to use the
feature all that often.

While we're on the topic of replica selection and discovery, let's also
bikeshed how to figure out how many replicas are even available.

(Yes, yes, the crazydragon rears his head again...;)

--D

[1] https://lore.kernel.org/linux-block/1543376991-5764-1-git-send-email-allison.henderson@oracle.com/

Re: [LSF/MM/BPF TOPIC] selectively cramming things onto struct bio

[Theodore Y. Ts'o]

On Thu, Jan 30, 2020 at 04:44:47PM -0800, Darrick J. Wong wrote:
> Hi everyone,
> 
> Several months ago, there was a discussion[1] about enhancing XFS to
> take a more active role in recoverying damaged blocks from a redundant
> storage device when the block device doesn't signal an error but the
> filesystem can tell that something is wrong.
> 
> Yes, we (XFS) would like to be able to exhaust all available storage
> redundancy before we resort to rebuilding lost metadata, and we'd like
> to do that without implementing our own RAID layer.
> 
> In the end, the largest stumbling block seems to be how to attach
> additional instructions to struct bio.  Jens rejected the idea of adding
> more pointers or more bytes to a struct bio since we'd be forcing
> everyone to pay the extra memory price for a feature that in the ideal
> situation will be used infrequently.

I'd be interested in this discussion as well; the issue came up when
adding support for hardware-based inline-crypto support.

							- Ted