[Top] [All Lists]

Re: failed to set versionnum in AG 1

To: Dave Chinner <david@xxxxxxxxxxxxx>
Subject: Re: failed to set versionnum in AG 1
From: Gabriel VLASIU <gabriel@xxxxxxxxxx>
Date: Tue, 6 Mar 2012 09:30:23 +0200 (EET)
Cc: xfs@xxxxxxxxxxx
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/simple; d=vlasiu.net; h= content-type:content-type:mime-version:user-agent:references :message-id:in-reply-to:subject:subject:from:from:date:date :received:received:received; s=default; t=1331019029; x= 1331022630; bh=WmUrCFdJC7mXiIYe7HHTc694Em+3mdeyIAB4z8AZF70=; b=n RILRGj2FOO/HOoQJ98EdBTwEeY7NkVEgougPLDl4aekKuH11AR2d7vEOuFv/8j0a GLxssHOX74BbEHSfCZyO6fnN/01IDNbRDOzQdZPgpLNHL6AgIwt7jmDDsaSjd26m RnCpC5mm+4M3QT7LLz7GKGGsZ2SXfARVwN0kjPqQ3g=
In-reply-to: <20120305222807.GE3592@dastard>
References: <alpine.LRH.2.02.1203041803340.8964@xxxxxxxxxxxxxxx> <20120305011032.GL5091@dastard> <alpine.LRH.2.02.1203050912001.10815@xxxxxxxxxxxxxxx> <20120305222807.GE3592@dastard>
User-agent: Alpine 2.02 (LRH 1266 2009-07-14)
Hash: SHA1


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.


- -- 

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

Version: GnuPG v1.4.11 (GNU/Linux)


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