On 4/11/17 1:43 PM, Brian Foster wrote:
> On Tue, Apr 11, 2017 at 01:34:25PM -0500, Eric Sandeen wrote:
>> On 4/11/17 1:30 PM, Brian Foster wrote:
>>> On Tue, Apr 11, 2017 at 04:12:36PM +0200, Jan Tulak wrote:
>>>> Add a warning about possible corruption when exporting a dirty log, as
>>>> the log content does not agree with obfuscated metadata.
>>>>
>>>> Signed-off-by: Jan Tulak <jtulak@xxxxxxxxxx>
>>>> ---
>>>
>>> Thanks for posting this...
>>>
>>>> db/metadump.c | 3 ++-
>>>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/db/metadump.c b/db/metadump.c
>>>> index 66952f6..74e24b2 100644
>>>> --- a/db/metadump.c
>>>> +++ b/db/metadump.c
>>>> @@ -2726,7 +2726,8 @@ copy_log(void)
>>>> /* keep the dirty log */
>>>> if (obfuscate)
>>>> print_warning(
>>>> -_("Filesystem log is dirty; image will contain unobfuscated metadata in log."));
>>>> +_("Filesystem log is dirty; image will contain unobfuscated metadata in log "
>>>> + "and a log replay can cause a corruption."));
>>>
>>> I think a slightly more verbose message might be a good idea. For
>>> example, something like the following:
>>>
>>> "Filesystem log is dirty; image will contain unobfuscated metadata in
>>> the log. Log recovery of an obfuscated image can cause filesystem
>>> corruption. Please mount the source image to clean the log or disable
>>> metadump obfuscation."
>>>
>>> That could also say "... or verify that log recovery of the resulting
>>> image does not cause corruption," but that might be overkill. Thoughts?
>>> Eric?
>>
>> I think we do need a good explanation, but that will take a lot of workd.
>> We could also refer to the man page for more details - it's getting pretty
>> long for a warning from the tool.
>>
>
> Hm, yeah. Maybe the existing warning can be condensed a bit more to
> something like:
>
> "Warning: log recovery of an obfuscated metadata image can leak
> unobfuscated metadata and/or cause filesystem corruption. Please mount
> the source image to clean the log or disable obfuscation."
s/filesystem corruption/image corruption/ - we don't want anyone to think
that it damaged the original fs!
> I suppose we could also just exit under such conditions unless the user
> passes a force flag or something. Maybe that's overkill too, though..
yeah, let's not overengineer - dumping a dirty, obfuscated log is quite
typical I think.
-Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
