* failed to set versionnum in AG 1 @ 2012-03-04 16:09 Gabriel VLASIU 2012-03-05 1:10 ` Dave Chinner 0 siblings, 1 reply; 5+ messages in thread From: Gabriel VLASIU @ 2012-03-04 16:09 UTC (permalink / raw) To: xfs -----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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: failed to set versionnum in AG 1 2012-03-04 16:09 failed to set versionnum in AG 1 Gabriel VLASIU @ 2012-03-05 1:10 ` Dave Chinner 2012-03-05 7:31 ` Gabriel VLASIU 0 siblings, 1 reply; 5+ messages in thread From: Dave Chinner @ 2012-03-05 1:10 UTC (permalink / raw) To: Gabriel VLASIU; +Cc: xfs 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: failed to set versionnum in AG 1 2012-03-05 1:10 ` Dave Chinner @ 2012-03-05 7:31 ` Gabriel VLASIU 2012-03-05 22:28 ` Dave Chinner 0 siblings, 1 reply; 5+ messages in thread From: Gabriel VLASIU @ 2012-03-05 7:31 UTC (permalink / raw) To: Dave Chinner; +Cc: xfs -----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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: failed to set versionnum in AG 1 2012-03-05 7:31 ` Gabriel VLASIU @ 2012-03-05 22:28 ` Dave Chinner 2012-03-06 7:30 ` Gabriel VLASIU 0 siblings, 1 reply; 5+ messages in thread From: Dave Chinner @ 2012-03-05 22:28 UTC (permalink / raw) To: Gabriel VLASIU; +Cc: xfs 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: failed to set versionnum in AG 1 2012-03-05 22:28 ` Dave Chinner @ 2012-03-06 7:30 ` Gabriel VLASIU 0 siblings, 0 replies; 5+ messages in thread From: Gabriel VLASIU @ 2012-03-06 7:30 UTC (permalink / raw) To: Dave Chinner; +Cc: xfs -----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 ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2012-03-06 7:30 UTC | newest] Thread overview: 5+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2012-03-04 16:09 failed to set versionnum in AG 1 Gabriel VLASIU 2012-03-05 1:10 ` Dave Chinner 2012-03-05 7:31 ` Gabriel VLASIU 2012-03-05 22:28 ` Dave Chinner 2012-03-06 7:30 ` Gabriel VLASIU
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox