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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

> 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@xxxxxxxxxxxxx

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



[Index of Archives]     [Linux XFS Devel]     [Linux Filesystem Development]     [Filesystem Testing]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux