[dm-devel] [PATCH v2] dm-integrity: if we have discard support, use it when recalculating
Melvin Vermeeren
vermeeren at vermwa.re
Wed May 5 21:47:41 UTC 2021
Hi,
On Wednesday, 5 May 2021 22:45:09 CEST Mikulas Patocka wrote:
> So, we can ask Milan to update the manpage.
Yes, that would be fine. However, "integrity recalculate" sounds like
recalculating integrity. The newly implemented logic is more of a "integrity
wipe" or "integrity reset".
What is problematic is that actual functionality from end user point of view
is now completely different depending on if you use --allow-discards or not.
Without discard you recalculate meta, with discard you reset/wipe meta.
> It will receive integrity protection for the newly written data.
>
> If you create an integrity device and make a filesystem on it, the newly
> written data matters. The old data that were on the filesystem before
> formatting it don't care and don't need to be protected.
One of the current possible use cases with --no-wipe --data-device is that you
can use existing device holding data that has no integrity and add integrity
to it with detached metadata device in combination with recalculate.
Then recalculation can be used in a fashion similar to trust-on-first-use for
this specific disk without rewriting the data meaning also no temporary copy
is needed. This feature is something I have used a few times as adding
integrity in-place can be useful in certain situations especially when dealing
with large amounts of data.
I am not against the new reset/wipe operation, it is certainly a useful thing
to have. This style of initialising metadata would be especially useful with
formatting devices supporting discard, as it could be used to avoid
unnecessary writes on main data by initialising metadata only (and perhaps
also issue discards to underlying device).
But I do think this should be a separate, new function in addition to existing
recalculation feature, to me they both seem useful in different use cases.
Thoughts on this?
Thanks,
--
Melvin Vermeeren
Systems engineer
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://listman.redhat.com/archives/dm-devel/attachments/20210505/6b610a35/attachment.sig>
More information about the dm-devel
mailing list