failed to set versionnum in AG 1

failed to set versionnum in AG 1

[Gabriel VLASIU]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi!

On all my older partitions with xfs I have this problem:

# xfs_db -x /dev/sdh1
xfs_db> version
versionnum [0xb4b4+0x8] = V4,ATTR,NLINK,ALIGN,DIRV2,LOGV2,EXTFLG,MOREBITS,ATTR2
xfs_db> version attr2
writing all SBs
Superblock has mismatched features2 fields, skipping modification
failed to set versionnum in AG 1
versionnum [0xb4b4+0x8] = V4,ATTR,NLINK,ALIGN,DIRV2,LOGV2,EXTFLG,MOREBITS,ATTR2

Some does not even has ATTR2 enabled and "version attr2" give the same 
error and ATTR2 get enabled.

Can this error be fixed and how? Should I worry about this?
Thank you.


Sincerely,
Gabriel

- -- 

// Gabriel VLASIU
//
// OpenGPG-KeyID      : 0xE684206E
// OpenGPG-Fingerprint: 0C3D 9F8B 725D E243 CB3C 8428 796A DB1F E684 206E
// OpenGPG-URL        : http://www.vlasiu.net/public.key


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEARECAAYFAk9Tk6gACgkQeWrbH+aEIG5wiwCdF+273blEdosPWCDNblJdvUAv
xqAAnRKt47B8zEbSbXArf3KJJhf1vcyD
=pqqw
-----END PGP SIGNATURE-----

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

Re: failed to set versionnum in AG 1

[Dave Chinner]

On Sun, Mar 04, 2012 at 06:09:12PM +0200, Gabriel VLASIU wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi!
> 
> On all my older partitions with xfs I have this problem:
> 
> # 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.

> xfs_db> version attr2
> writing all SBs
> Superblock has mismatched features2 fields, skipping modification
> failed to set versionnum in AG 1
> versionnum [0xb4b4+0x8] = V4,ATTR,NLINK,ALIGN,DIRV2,LOGV2,EXTFLG,MOREBITS,ATTR2

What version of xfs_db are you using?

And why do you need to set the attr2 feature this way? It gets set
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...

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

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

Re: failed to set versionnum in AG 1

[Gabriel VLASIU]

-----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.

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?

> > xfs_db> version attr2
> > writing all SBs
> > Superblock has mismatched features2 fields, skipping modification
> > failed to set versionnum in AG 1
> > 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

> And why do you need to set the attr2 feature this way? It gets set
> 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).

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".
Still, xfs_repair does not see anything wrong with the filesystem. So 
who's wrong? xfs_repair or xfs_db?
An most important: it's possible in the future to loose some data?

Sincerely,
Gabriel

- -- 

// Gabriel VLASIU
//
// OpenGPG-KeyID      : 0xE684206E
// OpenGPG-Fingerprint: 0C3D 9F8B 725D E243 CB3C 8428 796A DB1F E684 206E
// OpenGPG-URL        : http://www.vlasiu.net/public.key


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEARECAAYFAk9Ua9oACgkQeWrbH+aEIG6x/QCeOrLQCVrVbBnzT5UXmKy8bwdK
u/YAn1P3G2L80MMvX0qD0Tf25fBLleX+
=BZVM
-----END PGP SIGNATURE-----

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

Re: failed to set versionnum in AG 1

[Dave Chinner]

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@fromorbit.com

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

Re: failed to set versionnum in AG 1

[Gabriel VLASIU]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

 Hi!

On Tue, 6 Mar 2012, Dave Chinner wrote:

> 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.
I see.

> No, most definitely not. There's nothing wrong with your
> filesystems.
That's a very good news for me.

> 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.
I do not "poke" around filesystems with data. I use xfs in production 
since redhat 9. I do not know how old are the filesystems in question 
but some are probably more than 7-8 years old.
The only thing I set to those filesystem over the years is log2 attribute 
using xfs_admin (and the filesystem label). But since xfs_admin cannot set 
the ATTR2 I had to use xfs_db.

> "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.
Oh... I see. Thank you.

> 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...
OK. I'll keep that in mind.

> There's nothing wrong with either of them, likewise there is nothing
> really wrong with your filesystem.
However, it would be nice if xfs_repair would correct secondary 
superblock too.

> > An most important: it's possible in the future to loose some data?
> 
> No.
OK. That's what it really matter.

> 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:
Thanks, but I think I'm going to skip this. In the future maybe I will 
try-it but not for now.


Thank you very much for your help.


Sincerely,
Gabriel

- -- 

// Gabriel VLASIU
//
// OpenGPG-KeyID      : 0xE684206E
// OpenGPG-Fingerprint: 0C3D 9F8B 725D E243 CB3C 8428 796A DB1F E684 206E
// OpenGPG-URL        : http://www.vlasiu.net/public.key


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEARECAAYFAk9VvQ8ACgkQeWrbH+aEIG5+SgCfTGonFTC5exu67m1P6eU2PAPt
0IkAn3YFA3MZWsK8C4DSpFBNqIUxXWrU
=e+du
-----END PGP SIGNATURE-----

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