> Tying detection of transaction type numbering to an
> unrelated on-disk feature change is simply wrong. No ifs, not buts,
> it's just wrong.
Yes, I agree with you.
> Actually, it was introduced in 3.20-rc1, aka 4.0. It was propagated
> into xfsprogs 4.2.0-rc1. The trans type code in logprint is really
> for legacy filesystems with kernels older than 3.0.
> I don't see much point in trying to hack legacy support
> into the TOT diagnostic tool, especailly as it is trivial to pull
> a logprint from a previous release if such support is actually
> necessary. e.g:
>
> $ git checkout -b old_logprint v3.2.3
> $ make
>
> And now you have a logprint/xfs_logprint binary that you can use for
> diagnostics of the pre-delaylog log format.
>
> Removing functionality from the TOT code base does not mean that
> functionality is lost - it's still in the revision contorl system
> and a minute away from being usable if it's ever needed.
I just think about the compatibility things too much.
> Users won't know this, because "delaylog" is something that has long
> been deprecated and lots of users don't even know it exists.
>
> Really, just remove the transaction type printing from logprint and
> both developers and users can continue to ignore it like we have
> been for the past few years....
Thanks for your comment.
I will send a new patch to remove the transaction type printing.
|