Re: [PATCH] xfs_db: new -FF option help to continue the command without verify

[Zorro Lang <zlang@redhat.com>]

On Sat, Aug 27, 2016 at 10:43:18AM +1000, Dave Chinner wrote:
> On Fri, Aug 26, 2016 at 07:04:56PM +0800, Zorro Lang wrote:
> > When I try to do below steps(a V5 xfs on $fsile):
> > 
> >   # xfs_db -x -c "sb 0" -c "write features_ro_compat 4096" $fsfile
> >   # xfs_db -x -c "sb 0" -c "write features_ro_compat 0" $fsfile
> >   # xfs_db -c "sb 0" -c p $fsfile
> > 
> > The step#2 and #3 all failed, as:
> > 
> >   Superblock has unknown read-only compatible features (0x1000) enable
> 
> As it should. xfs_db *in expert mode* allows you to shoot yourself
> in the foot. However, it doesn't guarantee you'll have the expertise
> to be able to fix the hole you just shot in your foot.
> 
> You have much to learn, grasshopper. :P

So I wrote a *stupid* patch at here... HaHa, I'm not afraid to try more
*this* if I can learn more:)

Thanks so much you take time to explain lots of things for me. That's my
pleasure:) And they're very helpful for me, I'm trying to read more
man-pages and code for understand all you said below(Looks like I have
much things to do this weekend:-P)

Thanks,
Zorro

> 
> > If we break the superblock, at least xfs_db should help to print the
> > superblock info.
> 
> It should. You tried to write to it in expert mode, though. Try just
> printing the field in read-only mode (-r)....
> 
> > And as a xfs debugger, xfs_db should can ignore
> > unexpected errors to continue the "expert" command which an expert
> > want to do.
> 
> You're making the assumption that "-x" makes the user an expert.
> That is far from the truth - it just means someone read a man page,
> not that they have any specific XFS knowledge. The talk I
> gave at LCA 2015 is relevant here:
> 
> https://www.youtube.com/watch?v=VpuVDfSXs-g
> 
> I go into a bit of depth about how cognitive biases affect how
> people learn and assess their levels of expertise. This should
> explain why "expert" mode still needs /some/ safeguards.
> 
> Remember: feature flags are the most critical part of the on-disk
> format because they tell everything that parses the on-disk format
> what format exists on disk. If it is changed to something the tools
> don't recognise, the tools should /absolutely refuse/ to run in
> anything other than the mode indicated by the feature flags (i.e.
> read-only or not at all).
> 
> This, however, only turns off part of xfs_db's "make it
> easy-for-non-experts" automatic type detection functionality. If you
> know what you are doing and how xfs_db works (i.e. the user is an
> expert), this is trivial to get around.
> 
> So, let me demonstrate:
> 
> $ sudo xfs_db -x -c "sb 0" -c "write features_ro_compat 4096" /dev/vdc
> features_ro_compat = 0x1000
> $ sudo xfs_db -x -c "sb 0" -c "write features_ro_compat 0" /dev/vdc
> Superblock has unknown read-only compatible features (0x1000) enabled.
> Attempted to mount read-only compatible filesystem read-write.
> Filesystem can only be safely mounted read only.
> no current type
> $
> 
> Ok, there's an error there that tells me I can't decode the buffer
> that was loaded because automatic type detection was not run. So,
> lets load it as a raw buffer and set the type manually:
> 
> $ sudo xfs_db -r -c "daddr 0" -c "type sb" -c "p features_ro_compat" /dev/vdc
> Superblock has unknown read-only compatible features (0x1000) enabled.
> Attempted to mount read-only compatible filesystem read-write.
> Filesystem can only be safely mounted read only.
> features_ro_compat = 0x1000
> 
> Yup, there we go, access to the superblock type parsing is
> re-enabled by starting with a raw data buffer, then setting the type
> manually. We probably should fix userspace to then remount in
> read-only mode so this works correctly without needing this step.
> (It's probably just a libxfs init flag that is wrong.)
> 
> So:
> 
> $ sudo xfs_db -x -c "daddr 0" -c "type sb" -c "write features_ro_compat 0" /dev/vdc
> Superblock has unknown read-only compatible features (0x1000) enabled.
> Attempted to mount read-only compatible filesystem read-write.
> Filesystem can only be safely mounted read only.
> features_ro_compat = 0
> $ sudo xfs_db -r -c "sb 0" -c "p features_ro_compat" /dev/vdc
> features_ro_compat = 0
> $
> 
> Yup, I just reset it to zero with expert mode, simply by knowing how
> xfs_db works and avoiding the error that occurred with automatic type
> detection. But even if I can't set the type manually, I can still
> fix this by going back to first principles.
> 
> $ sudo xfs_db -x -c "sb 0" -c "write features_ro_compat 4096" /dev/vdc
> features_ro_compat = 0x1000
> $
> 
> First - manually find the on-disk format structure offset:
> 
> $ pahole fs/xfs/libxfs/xfs_sb.o |grep sb_features_ro_compat
> 	__uint32_t                 sb_features_ro_compat; /*   212     4 */
> 	__be32                     sb_features_ro_compat; /*   212     4 */
> $
> 
> Now we can just write zeros directly to the raw buffer, then check
> it by re-reading the superblock using the automatic type detection:
> 
> $ sudo xfs_db -x -c "daddr 0" -c "write fill 0 212 4" -c "sb 0" -c "p features_ro_compat" /dev/vdc
> features_ro_compat = 0
> 
> Yup, problem solved.  But:
> 
> $ sudo xfs_db -r -c "sb 0" -c "p features_ro_compat" /dev/vdc
> Metadata CRC error detected at xfs_sb block 0x0/0x200
> features_ro_compat = 0
> 
> It's not a clean solution for v5 filesystems - I have to recalc the
> CRC. Previous I would have simply run xfs_repair to fix this, but
> now I can do this:
> 
> $ sudo xfs_db -x -c "sb 0" -c "crc" -c "crc -r" /dev/vdc
> Verifying CRC:
> crc = 0xdea3392d (bad)
> Recalculating CRC:
> crc = 0x3a7763c8 (correct)
> $ sudo xfs_db -r -c "sb 0" -c "p features_ro_compat" /dev/vdc
> features_ro_compat = 0
> $
> 
> And now it's all good.
> 
> So, as you can see we have /multiple ways/ we can fix bad feature
> fields with xfs_db. None of them require magic force flags, but it
> does require the ability to solve problems from first principles.
> 
> Cheers,
> 
> Dave.
> -- 
> Dave Chinner
> david@fromorbit.com
> 
> _______________________________________________
> xfs mailing list
> xfs@oss.sgi.com
> http://oss.sgi.com/mailman/listinfo/xfs

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs