xfs
[Top] [All Lists]

Re: failed to set versionnum in AG 1

To: Gabriel VLASIU <gabriel@xxxxxxxxxx>
Subject: Re: failed to set versionnum in AG 1
From: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Tue, 6 Mar 2012 09:28:07 +1100
Cc: xfs@xxxxxxxxxxx
In-reply-to: <alpine.LRH.2.02.1203050912001.10815@xxxxxxxxxxxxxxx>
References: <alpine.LRH.2.02.1203041803340.8964@xxxxxxxxxxxxxxx> <20120305011032.GL5091@dastard> <alpine.LRH.2.02.1203050912001.10815@xxxxxxxxxxxxxxx>
User-agent: Mutt/1.5.21 (2010-09-15)
On Mon, Mar 05, 2012 at 09:31:38AM +0200, Gabriel VLASIU wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi Dave!
> 
> On Mon, 5 Mar 2012, Dave Chinner wrote:
> 
> > > # xfs_db -x /dev/sdh1
> > > xfs_db> version
> > > versionnum [0xb4b4+0x8] = 
> > > V4,ATTR,NLINK,ALIGN,DIRV2,LOGV2,EXTFLG,MOREBITS,ATTR2
> > 
> > it already has the attr2 feature bit set.
> Yes, it has. But another (old) partition does not have ATTR2 enabled. And 
> the error is the same when I try to set ATTR2. And the funny thing is, 
> after that, version report ATTR2 as set.

That's because the error you are getting is for setting the value
into secondary superblocks, but the primary superblock has had the
value set correctly.

> All my partitions have been created on RHEL5 (some are even older). On a 
> new partition (created on RHEL6) I can set ATTR2 over and over again 
> without any error reported. Should I backup everything, reformat all 
> partitions and restore everything?

No, most definitely not. There's nothing wrong with your
filesystems.

> > > xfs_db> version attr2
> > > writing all SBs
> > > Superblock has mismatched features2 fields, skipping modification
> > > failed to set versionnum in AG 1

That's a secondary superblock it failed on - the kernel never reads
or writes the secondary superblocks (execpt during a grow operation)
and repair will fix any mismatches if the primary gets trashed so
the error is pretty much irrelevant...

> > > versionnum [0xb4b4+0x8] = 
> > > V4,ATTR,NLINK,ALIGN,DIRV2,LOGV2,EXTFLG,MOREBITS,ATTR2
> > 
> > What version of xfs_db are you using?
> 3.1.1 and 3.1.7

So you're using the versions that detect inconsistencies correctly,
and also write everythign consistently. So it's a problem from an
old mkfs binary (2.9.x or 3.0.x) or caused by something you've done
poking around with xfs_db.

> > automatically when it gets used because on recent kernels it is the
> > default mount option. If you have an older kernel and need to turn
> > attr2 on, then simply add the "attr2" field to the mount options on
> > the filesystem. Once xfs_info reports attr=2 for the filesytem, you
> > can remove the attr2 mount option...
> Thank you, but I know that. In fact it was the first thing I tried: can 
> the filesystem be be mounted if I add attr2 is in fstab. And I was able to 
> do so. Still, ATTR2 was not reported for the partition I was talking 
> above (without ATTR2 reported by version).

You didn't say that. Go back and read what I said, though:

"Once xfs_info reports attr=2 for the filesytem, you
can remove the attr2 mount option..."

The attr2 feature bit will only get set when the attr2 format
is first used, so if you're workload isn't causing attr2 format
inodes to be created, the feature bit will not get set. Hence you
need to leave the mount option set until xfs_info (which reads the
superblock feature bits) reports it being set.

> But that's not the point. I see an error message here "Superblock has 
> >>mismatched<< features2 fields". And another one ">>failed<< to set 
> versionnum in AG 1".

Yes, I know, but that's a secondary issue because you should not
*ever* need to use xfs_db to set the attr2 feature field, not to
mention that the primary superblock already has the correct bits set
and the secondaries are not actually required at runtime.

IOWs, if you have to resort to using xfs_db to set a feature bit,
you are doing something wrong. xfs_admin and/or mount options give
you control over all feature bits that are safe for user
modification...

> Still, xfs_repair does not see anything wrong with the filesystem. So 
> who's wrong? xfs_repair or xfs_db?

There's nothing wrong with either of them, likewise there is nothing
really wrong with your filesystem.

> An most important: it's possible in the future to loose some data?

No.

So, if you want to make everything absolutely consistent with xfs_db
(seeing as something is inconsistenti as a result of either the age
of the filesystems or the poking you've done) then you need to copy
the sb_features2 field to sb_bad_features2 field in every secondary
superblock. i.e. something like:

xfs_db -c "sb 0" -c "print features2" <dev>
<value>

for i in `seq 1 1 <number of ags in fs>`; do
        xfs_db -x -c "sb $i" -c "write features2 <value>" \
                             -c "write bad_features2 <value>" <dev>
done

And that will set all the features2 and bad_features2 fields to the
same value as in the primary superblock.

Cheers,

Dave.
-- 
Dave Chinner
david@xxxxxxxxxxxxx

<Prev in Thread] Current Thread [Next in Thread>