> 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. _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
