Re: [dm-devel] [PATCH v2] dm-integrity: if we have discard support, use it when recalculating

[Melvin Vermeeren <vermeeren@vermwa.re>]

[-- Attachment #1.1: Type: text/plain, Size: 1932 bytes --]

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

[-- Attachment #1.2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 97 bytes --]

--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/listinfo/dm-devel