Differences in mkfs.xfs and xfs_info output.

Differences in mkfs.xfs and xfs_info output.

[Jan Derfinak]

Hello.

I found following problem with xfs_info (xfs_grows -p xfs_info) command:

# mkfs.xfs -f /dev/loop0     
meta-data=/dev/loop0             isize=256    agcount=4, agsize=32000 blks
         =                       sectsz=512   attr=2
data     =                       bsize=4096   blocks=128000, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096  
log      =internal log           bsize=4096   blocks=1200, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0
# mount /dev/loop0 /mnt/usb
# xfs_info /mnt/usb
meta-data=/dev/loop0             isize=256    agcount=4, agsize=32000 blks
         =                       sectsz=512   attr=0
data     =                       bsize=4096   blocks=128000, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096  
log      =internal               bsize=4096   blocks=1200, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=0
realtime =none                   extsz=4096   blocks=0, rtextents=0

Can somebody explain the difference in attr and lazy-count parameters?
Which output is the right one?

mkfs.xfs version 2.9.6
SGI-XFS CVS-2008-02-14_08:00_UTC with ACLs, large block/inode numbers, no debug enabled
SGI XFS Quota Management subsystem
architecture x86_64

# xfs_db -r /dev/loop0 
xfs_db> sb
xfs_db> print
magicnum = 0x58465342
blocksize = 4096
dblocks = 128000
rblocks = 0
rextents = 0
uuid = 925f5530-62d4-4385-ad9e-e5c72e2fb609
logstart = 65540
rootino = 128
rbmino = 129
rsumino = 130
rextsize = 1
agblocks = 32000
agcount = 4
rbmblocks = 0
logblocks = 1200
versionnum = 0xb4a4
sectsize = 512
inodesize = 256
inopblock = 16
fname = "\000\000\000\000\000\000\000\000\000\000\000\000"
blocklog = 12
sectlog = 9
inodelog = 8
inopblog = 4
agblklog = 15
rextslog = 0
inprogress = 0
imax_pct = 25
icount = 64
ifree = 61
fdblocks = 126780
frextents = 0
uquotino = 0
gquotino = 0
qflags = 0
flags = 0
shared_vn = 0
inoalignmt = 2
unit = 0
width = 0
dirblklog = 0
logsectlog = 0
logsectsize = 0
logsunit = 1
features2 = 0

Thanks,
Jan

-- 

Re: Differences in mkfs.xfs and xfs_info output.

[Eric Sandeen]

Jan Derfinak wrote:
> Hello.
> 
> I found following problem with xfs_info (xfs_grows -p xfs_info) command:
> 
> # mkfs.xfs -f /dev/loop0     
> meta-data=/dev/loop0             isize=256    agcount=4, agsize=32000 blks
>          =                       sectsz=512   attr=2
> data     =                       bsize=4096   blocks=128000, imaxpct=25
>          =                       sunit=0      swidth=0 blks
> naming   =version 2              bsize=4096  
> log      =internal log           bsize=4096   blocks=1200, version=2
>          =                       sectsz=512   sunit=0 blks, lazy-count=1
> realtime =none                   extsz=4096   blocks=0, rtextents=0
> # mount /dev/loop0 /mnt/usb
> # xfs_info /mnt/usb
> meta-data=/dev/loop0             isize=256    agcount=4, agsize=32000 blks
>          =                       sectsz=512   attr=0
> data     =                       bsize=4096   blocks=128000, imaxpct=25
>          =                       sunit=0      swidth=0 blks
> naming   =version 2              bsize=4096  
> log      =internal               bsize=4096   blocks=1200, version=2
>          =                       sectsz=512   sunit=0 blks, lazy-count=0
> realtime =none                   extsz=4096   blocks=0, rtextents=0
> 
> Can somebody explain the difference in attr and lazy-count parameters?
> Which output is the right one?

...

> features2 = 0


Looks like neither XFS_SB_VERSION2_ATTR2BIT nor
XFS_SB_VERSION2_LAZYSBCOUNTBIT is in fact set.

You're on x86_64 aren't you...

This reminds me of an email I sent in 2006....

> If you do a fresh mkfs.xfs on x86_64, with -i attr=2, and dump out the
> superblock (or look at it with xfs_db) you will find that although the
> versionnum says that there is a morebits bit, the features2 flag is 0.
> 
> if you dd/hexdump the superblock, you will find the attr2 flag, but at
> the wrong offset.
> 
> This is because the xfs_sb_t struct is padded out to 64 bits on 64-bit
> arches, and the xfs_xlatesb() routine and xfs_sb_info[] array take this
> padding to mean that the last item is 4 bytes bigger than it is, and
> treats sb_features2 as 8 bytes not four.  This then gets endian-flipped out...

which is exactly what is (still) going on.

if you hexdump out the filesystem that was made you'll see:

....
          sbqf  sv vn inode_algn   sbunit      sbwidth
000000b0  00 00 00 00 00 00 00 02  00 00 00 00 00 00 00 00
|................|
          bl sl lgss     logsunit  features2   (nothing)
000000c0  00 00 00 00 00 00 00 01  00 00 00 00 00 00 00 08
|................|

that "08" out in no mans land is what would *like* to be features2 - and
if it were, it'd give you attr2.  Urk.

-Eric

Re: Differences in mkfs.xfs and xfs_info output.

[Eric Sandeen]

Eric Sandeen wrote:

> Jan Derfinak wrote:
>   
>> features2 = 0
>>     
>
>
> Looks like neither XFS_SB_VERSION2_ATTR2BIT nor
> XFS_SB_VERSION2_LAZYSBCOUNTBIT is in fact set.
>
> You're on x86_64 aren't you...
>
> This reminds me of an email I sent in 2006....
>   
Does this make it happier for you?  Hmm actually the kernel needs
the analogous change too.  And then probably something to fix up 
all the misformatted filesystems out there.... yuck.

Hmm and I don't know how lazy-sb-count is getting lost, yet :)

Index: xfsprogs/include/xfs_sb.h
===================================================================
--- xfsprogs.orig/include/xfs_sb.h
+++ xfsprogs/include/xfs_sb.h
@@ -151,6 +151,7 @@ typedef struct xfs_sb
 	__uint16_t	sb_logsectsize;	/* sector size for the log, bytes */
 	__uint32_t	sb_logsunit;	/* stripe unit size for the log */
 	__uint32_t	sb_features2;	/* additional feature bits */
+	__uint32_t	sb_dummy;	/* explicit padding */
 } xfs_sb_t;
 
 /*
@@ -169,7 +170,7 @@ typedef enum {
 	XFS_SBS_GQUOTINO, XFS_SBS_QFLAGS, XFS_SBS_FLAGS, XFS_SBS_SHARED_VN,
 	XFS_SBS_INOALIGNMT, XFS_SBS_UNIT, XFS_SBS_WIDTH, XFS_SBS_DIRBLKLOG,
 	XFS_SBS_LOGSECTLOG, XFS_SBS_LOGSECTSIZE, XFS_SBS_LOGSUNIT,
-	XFS_SBS_FEATURES2,
+	XFS_SBS_FEATURES2, XFS_SBS_DUMMY,
 	XFS_SBS_FIELDCOUNT
 } xfs_sb_field_t;
 
Index: xfsprogs/libxfs/xfs_mount.c
===================================================================
--- xfsprogs.orig/libxfs/xfs_mount.c
+++ xfsprogs/libxfs/xfs_mount.c
@@ -140,6 +140,7 @@ static struct {
     { offsetof(xfs_sb_t, sb_logsectsize),0 },
     { offsetof(xfs_sb_t, sb_logsunit),	 0 },
     { offsetof(xfs_sb_t, sb_features2),	 0 },
+    { offsetof(xfs_sb_t, sb_dummy),	 0 },
     { sizeof(xfs_sb_t),			 0 }
 };
 

Re: Differences in mkfs.xfs and xfs_info output.

[Eric Sandeen]

Eric Sandeen wrote:

> Hmm and I don't know how lazy-sb-count is getting lost, yet :)

oh same reason of course.  it's just that on my mkfs lazy-count isn't
default...

-Eric

Re: Differences in mkfs.xfs and xfs_info output.

[Eric Sandeen]

Jan Derfinak wrote:
> Hello.
> 
> I found following problem with xfs_info (xfs_grows -p xfs_info) command:
> 
> # mkfs.xfs -f /dev/loop0     
> meta-data=/dev/loop0             isize=256    agcount=4, agsize=32000 blks
>          =                       sectsz=512   attr=2
> data     =                       bsize=4096   blocks=128000, imaxpct=25
>          =                       sunit=0      swidth=0 blks
> naming   =version 2              bsize=4096  
> log      =internal log           bsize=4096   blocks=1200, version=2
>          =                       sectsz=512   sunit=0 blks, lazy-count=1
> realtime =none                   extsz=4096   blocks=0, rtextents=0
> # mount /dev/loop0 /mnt/usb
> # xfs_info /mnt/usb
> meta-data=/dev/loop0             isize=256    agcount=4, agsize=32000 blks
>          =                       sectsz=512   attr=0
> data     =                       bsize=4096   blocks=128000, imaxpct=25
>          =                       sunit=0      swidth=0 blks
> naming   =version 2              bsize=4096  
> log      =internal               bsize=4096   blocks=1200, version=2
>          =                       sectsz=512   sunit=0 blks, lazy-count=0
> realtime =none                   extsz=4096   blocks=0, rtextents=0

... sorry for replying to my own thread 100 times, but...

do you happen to have a 32-bit mkfs and a 64-bit kernrel?

-Eric

Re: Differences in mkfs.xfs and xfs_info output.

[David Chinner]

On Sat, Feb 16, 2008 at 02:34:08AM +0100, Jan Derfinak wrote:
> Hello.
> 
> I found following problem with xfs_info (xfs_grows -p xfs_info) command:
> 
> # mkfs.xfs -f /dev/loop0     
> meta-data=/dev/loop0             isize=256    agcount=4, agsize=32000 blks
>          =                       sectsz=512   attr=2
> data     =                       bsize=4096   blocks=128000, imaxpct=25
>          =                       sunit=0      swidth=0 blks
> naming   =version 2              bsize=4096  
> log      =internal log           bsize=4096   blocks=1200, version=2
>          =                       sectsz=512   sunit=0 blks, lazy-count=1
> realtime =none                   extsz=4096   blocks=0, rtextents=0
> # mount /dev/loop0 /mnt/usb
> # xfs_info /mnt/usb
> meta-data=/dev/loop0             isize=256    agcount=4, agsize=32000 blks
>          =                       sectsz=512   attr=0
> data     =                       bsize=4096   blocks=128000, imaxpct=25
>          =                       sunit=0      swidth=0 blks
> naming   =version 2              bsize=4096  
> log      =internal               bsize=4096   blocks=1200, version=2
>          =                       sectsz=512   sunit=0 blks, lazy-count=0
> realtime =none                   extsz=4096   blocks=0, rtextents=0
> 
> Can somebody explain the difference in attr and lazy-count parameters?
> Which output is the right one?
.....
> # xfs_db -r /dev/loop0 
> xfs_db> sb
> xfs_db> print
....
> features2 = 0

That's why.

I've been meaning to push out a patch to fix this - just haven't
had time. The patch below should fix the problem - mkfs.xfs is writing
the features2 field to the wrong location in the superblock, and
this patch detects and corrects it. You'll probably see the output:

XFS: correcting sb_features alignment problem

in dmesg when you first mount the filesystem with the patched
kernel, and then it won't appear again (unless you mkfs it again).

Cheers,

Dave.
-- 
Dave Chinner
Principal Engineer
SGI Australian Software Group

---
 fs/xfs/xfs_mount.c |   34 ++++++++++++++++++++++++++++------
 fs/xfs/xfs_sb.h    |   37 ++++++++++++++++++++++++++++++++++---
 2 files changed, 62 insertions(+), 9 deletions(-)

Index: 2.6.x-xfs-new/fs/xfs/xfs_mount.c
===================================================================
--- 2.6.x-xfs-new.orig/fs/xfs/xfs_mount.c	2007-11-22 10:25:25.590278381 +1100
+++ 2.6.x-xfs-new/fs/xfs/xfs_mount.c	2007-11-22 10:31:27.891999961 +1100
@@ -44,7 +44,7 @@
 #include "xfs_quota.h"
 #include "xfs_fsops.h"
 
-STATIC void	xfs_mount_log_sbunit(xfs_mount_t *, __int64_t);
+STATIC void	xfs_mount_log_sb(xfs_mount_t *, __int64_t);
 STATIC int	xfs_uuid_mount(xfs_mount_t *);
 STATIC void	xfs_uuid_unmount(xfs_mount_t *mp);
 STATIC void	xfs_unmountfs_wait(xfs_mount_t *);
@@ -119,6 +119,7 @@ static const struct {
     { offsetof(xfs_sb_t, sb_logsectsize),0 },
     { offsetof(xfs_sb_t, sb_logsunit),	 0 },
     { offsetof(xfs_sb_t, sb_features2),	 0 },
+    { offsetof(xfs_sb_t, sb_bad_features2), 0 },
     { sizeof(xfs_sb_t),			 0 }
 };
 
@@ -455,6 +456,7 @@ xfs_sb_from_disk(
 	to->sb_logsectsize = be16_to_cpu(from->sb_logsectsize);
 	to->sb_logsunit = be32_to_cpu(from->sb_logsunit);
 	to->sb_features2 = be32_to_cpu(from->sb_features2);
+	to->sb_bad_features2 = be32_to_cpu(from->sb_bad_features2);
 }
 
 /*
@@ -976,6 +978,26 @@ xfs_mountfs(
 	xfs_mount_common(mp, sbp);
 
 	/*
+	 * Check for a bad features2 field alignment. This happened on
+	 * some platforms due to xfs_sb_t not being 64bit size aligned
+	 * when sb_features was added and hence the compiler put it in
+	 * the wrong place.
+	 *
+	 * If we detect a bad field, we or the set bits into the existing
+	 * features2 field in case it has already been modified and we
+	 * don't want to lose any features. Zero the bad one and mark
+	 * the two fields as needing updates once the transaction subsystem
+	 * is online.
+	 */
+	if (xfs_sb_has_bad_features2(sbp)) {
+		cmn_err(CE_WARN,
+			"XFS: correcting sb_features alignment problem");
+		sbp->sb_features2 |= sbp->sb_bad_features2;
+		sbp->sb_bad_features2 = 0;
+		update_flags |= XFS_SB_FEATURES2 | XFS_SB_BAD_FEATURES2;
+	}
+
+	/*
 	 * Check if sb_agblocks is aligned at stripe boundary
 	 * If sb_agblocks is NOT aligned turn off m_dalign since
 	 * allocator alignment is within an ag, therefore ag has
@@ -1165,11 +1187,10 @@ xfs_mountfs(
 	}
 
 	/*
-	 * If fs is not mounted readonly, then update the superblock
-	 * unit and width changes.
+	 * If fs is not mounted readonly, then update the superblock changes.
 	 */
 	if (update_flags && !(mp->m_flags & XFS_MOUNT_RDONLY))
-		xfs_mount_log_sbunit(mp, update_flags);
+		xfs_mount_log_sb(mp, update_flags);
 
 	/*
 	 * Initialise the XFS quota management subsystem for this mount
@@ -1884,13 +1905,14 @@ xfs_uuid_unmount(
  * be altered by the mount options. Only the first superblock is updated.
  */
 STATIC void
-xfs_mount_log_sbunit(
+xfs_mount_log_sb(
 	xfs_mount_t	*mp,
 	__int64_t	fields)
 {
 	xfs_trans_t	*tp;
 
-	ASSERT(fields & (XFS_SB_UNIT|XFS_SB_WIDTH|XFS_SB_UUID));
+	ASSERT(fields & (XFS_SB_UNIT | XFS_SB_WIDTH | XFS_SB_UUID |
+			 XFS_SB_FEATURES2 | XFS_SB_BAD_FEATURES2));
 
 	tp = xfs_trans_alloc(mp, XFS_TRANS_SB_UNIT);
 	if (xfs_trans_reserve(tp, 0, mp->m_sb.sb_sectsize + 128, 0, 0,
Index: 2.6.x-xfs-new/fs/xfs/xfs_sb.h
===================================================================
--- 2.6.x-xfs-new.orig/fs/xfs/xfs_sb.h	2007-11-22 10:25:25.598277360 +1100
+++ 2.6.x-xfs-new/fs/xfs/xfs_sb.h	2007-11-22 10:31:27.891999961 +1100
@@ -89,6 +89,7 @@ struct xfs_mount;
 
 /*
  * Superblock - in core version.  Must match the ondisk version below.
+ * Must be padded to 64 bit alignment.
  */
 typedef struct xfs_sb {
 	__uint32_t	sb_magicnum;	/* magic number == XFS_SB_MAGIC */
@@ -145,10 +146,21 @@ typedef struct xfs_sb {
 	__uint16_t	sb_logsectsize;	/* sector size for the log, bytes */
 	__uint32_t	sb_logsunit;	/* stripe unit size for the log */
 	__uint32_t	sb_features2;	/* additional feature bits */
+
+	/*
+	 * bad features2 field as a result of failing to pad the sb
+	 * structure to 64 bits. Some machines will be using this field
+	 * for features2 bits. Easiest just to mark it bad and not use
+	 * it for anything else.
+	 */
+	__uint32_t	sb_bad_features2;
+
+	/* must be padded to 64 bit alignment */
 } xfs_sb_t;
 
 /*
- * Superblock - on disk version.  Must match the in core version below.
+ * Superblock - on disk version.  Must match the in core version above.
+ * Must be padded to 64 bit alignment.
  */
 typedef struct xfs_dsb {
 	__be32		sb_magicnum;	/* magic number == XFS_SB_MAGIC */
@@ -205,6 +217,15 @@ typedef struct xfs_dsb {
 	__be16		sb_logsectsize;	/* sector size for the log, bytes */
 	__be32		sb_logsunit;	/* stripe unit size for the log */
 	__be32		sb_features2;	/* additional feature bits */
+	/*
+	 * bad features2 field as a result of failing to pad the sb
+	 * structure to 64 bits. Some machines will be using this field
+	 * for features2 bits. Easiest just to mark it bad and not use
+	 * it for anything else.
+	 */
+	__be32	sb_bad_features2;
+
+	/* must be padded to 64 bit alignment */
 } xfs_dsb_t;
 
 /*
@@ -223,7 +244,7 @@ typedef enum {
 	XFS_SBS_GQUOTINO, XFS_SBS_QFLAGS, XFS_SBS_FLAGS, XFS_SBS_SHARED_VN,
 	XFS_SBS_INOALIGNMT, XFS_SBS_UNIT, XFS_SBS_WIDTH, XFS_SBS_DIRBLKLOG,
 	XFS_SBS_LOGSECTLOG, XFS_SBS_LOGSECTSIZE, XFS_SBS_LOGSUNIT,
-	XFS_SBS_FEATURES2,
+	XFS_SBS_FEATURES2, XFS_SBS_BAD_FEATURES2,
 	XFS_SBS_FIELDCOUNT
 } xfs_sb_field_t;
 
@@ -248,13 +269,15 @@ typedef enum {
 #define XFS_SB_IFREE		XFS_SB_MVAL(IFREE)
 #define XFS_SB_FDBLOCKS		XFS_SB_MVAL(FDBLOCKS)
 #define XFS_SB_FEATURES2	XFS_SB_MVAL(FEATURES2)
+#define XFS_SB_BAD_FEATURES2	XFS_SB_MVAL(BAD_FEATURES2)
 #define	XFS_SB_NUM_BITS		((int)XFS_SBS_FIELDCOUNT)
 #define	XFS_SB_ALL_BITS		((1LL << XFS_SB_NUM_BITS) - 1)
 #define	XFS_SB_MOD_BITS		\
 	(XFS_SB_UUID | XFS_SB_ROOTINO | XFS_SB_RBMINO | XFS_SB_RSUMINO | \
 	 XFS_SB_VERSIONNUM | XFS_SB_UQUOTINO | XFS_SB_GQUOTINO | \
 	 XFS_SB_QFLAGS | XFS_SB_SHARED_VN | XFS_SB_UNIT | XFS_SB_WIDTH | \
-	 XFS_SB_ICOUNT | XFS_SB_IFREE | XFS_SB_FDBLOCKS | XFS_SB_FEATURES2)
+	 XFS_SB_ICOUNT | XFS_SB_IFREE | XFS_SB_FDBLOCKS | XFS_SB_FEATURES2 | \
+	 XFS_SB_BAD_FEATURES2)
 
 
 /*
@@ -297,6 +320,14 @@ static inline int xfs_sb_good_version(xf
 }
 #endif /* __KERNEL__ */
 
+/*
+ * Detect a bad features2 field
+ */
+static inline int xfs_sb_has_bad_features2(xfs_sb_t *sbp)
+{
+	return (sbp->sb_bad_features2 != 0);
+}
+
 #define	XFS_SB_VERSION_TONEW(v)	xfs_sb_version_tonew(v)
 static inline unsigned xfs_sb_version_tonew(unsigned v)
 {

Re: Differences in mkfs.xfs and xfs_info output.

[Jan Derfinak]

Thanks Eric and David.


On Sat, 16 Feb 2008, Eric Sandeen wrote:

> You're on x86_64 aren't you...

Yes, as I wrote in my mail architecture is x86_64.

> if you hexdump out the filesystem that was made you'll see

Here is hexdump:
00000000  58 46 53 42 00 00 10 00  00 00 00 00 00 01 f4 00  |XFSB............|
00000010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000020  92 5f 55 30 62 d4 43 85  ad 9e e5 c7 2e 2f b6 09  |._U0b.C....../..|
00000030  00 00 00 00 00 01 00 04  00 00 00 00 00 00 00 80  |................|
00000040  00 00 00 00 00 00 00 81  00 00 00 00 00 00 00 82  |................|
00000050  00 00 00 01 00 00 7d 00  00 00 00 04 00 00 00 00  |......}.........|
00000060  00 00 04 b0 b4 a4 02 00  01 00 00 10 00 00 00 00  |................|
00000070  00 00 00 00 00 00 00 00  0c 09 08 04 0f 00 00 19  |................|
00000080  00 00 00 00 00 00 00 40  00 00 00 00 00 00 00 3d  |.......@.......=|
00000090  00 00 00 00 00 01 ef 3c  00 00 00 00 00 00 00 00  |.......<........|
000000a0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000000b0  00 00 00 00 00 00 00 02  00 00 00 00 00 00 00 00  |................|
000000c0  00 00 00 00 00 00 00 01  00 00 00 00 00 00 00 0a  |................|
000000d0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000200  58 41 47 46 00 00 00 01  00 00 00 00 00 00 7d 00  |XAGF..........}.|
00000210  00 00 00 01 00 00 00 02  00 00 00 00 00 00 00 01  |................|
00000220  00 00 00 01 00 00 00 00  00 00 00 00 00 00 00 03  |................|
00000230  00 00 00 04 00 00 7c f4  00 00 7c f4 00 00 00 00  |......|...|.....|
00000240  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*

> Does this make it happier for you?  Hmm actually the kernel needs
> the analogous change too.  And then probably something to fix up 
> all the misformatted filesystems out there.... yuck.

The patched mkfs corretly sets attr2 and lazy-count. If I understand
right it is a long lasting bug. Are there any plans to fix mkfs?

> do you happen to have a 32-bit mkfs and a 64-bit kernrel?

No, both mkfs and kernel are 64-bit:
# file `which mkfs.xfs`
/sbin/mkfs.xfs: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), for GNU/Linux 2.6.4, dynamically linked (uses shared libs), not stripped
# ldd `which mkfs.xfs`
        linux-vdso.so.1 =>  (0x00007fffe97fe000)
        libuuid.so.1 => /lib64/libuuid.so.1 (0x00002ae4c15ba000)
        librt.so.1 => /lib64/librt.so.1 (0x00002ae4c17be000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00002ae4c19c7000)
        libc.so.6 => /lib64/libc.so.6 (0x00002ae4c1be3000)
        /lib64/ld-linux-x86-64.so.2 (0x00002ae4c139d000)

On Sat, 16 Feb 2008, David Chinner wrote:

> had time. The patch below should fix the problem - mkfs.xfs is writing
> the features2 field to the wrong location in the superblock, and
> this patch detects and corrects it. You'll probably see the output:

I confirm that your patch fix feature2 on previously created fs's:

dmesg:
XFS: correcting sb_features alignment problem
XFS mounting filesystem dm-0
Ending clean XFS mount for filesystem: dm-0

# xfs_info /usr
meta-data=/dev/mapper/system-usr isize=256    agcount=4, agsize=170496 blks
         =                       sectsz=512   attr=2
data     =                       bsize=4096   blocks=681984, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096  
log      =internal               bsize=4096   blocks=2560, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0
# xfs_db -r /dev/mapper/system-usr 
xfs_db> sb
xfs_db> print
magicnum = 0x58465342
blocksize = 4096
dblocks = 681984
.
.
.
logsunit = 1
features2 = 0xa


Cheers,

jan


-- 

Re: Differences in mkfs.xfs and xfs_info output.

[Jan Derfinak]

On Sat, 16 Feb 2008, David Chinner wrote:

> had time. The patch below should fix the problem - mkfs.xfs is writing
> the features2 field to the wrong location in the superblock, and
> this patch detects and corrects it. You'll probably see the output:

I would like to ask if correcting the feature2 field can lead to this
message?:
# xfs_check /dev/system/mnt
sb_fdblocks 190009, counted 191033
sb_fdblocks 190009, aggregate AGF count 191033

"local" is copy (dd) of other corrected FS
# xfs_check local
sb_fdblocks 163441, counted 165489
sb_fdblocks 163441, aggregate AGF count 165489
# xfs_repair -v local
Phase 1 - find and verify superblock...
        - block cache size set to 96240 entries
Phase 2 - using internal log
        - zero log...
zero_log: head block 120967 tail block 120967
        - scan filesystem freespace and inode maps...
        - found root inode chunk
Phase 3 - for each AG...
        - scan and clear agi unlinked lists...
        - process known inodes and perform inode discovery...
        - agno = 0
        - agno = 1
        - agno = 2
        - agno = 3
        - process newly discovered inodes...
Phase 4 - check for duplicate blocks...
        - setting up duplicate extent list...
        - check for inodes claiming duplicate blocks...
        - agno = 0
        - agno = 1
        - agno = 2
        - agno = 3
Phase 5 - rebuild AG headers and trees...
        - agno = 0
        - agno = 1
        - agno = 2
        - agno = 3
        - reset superblock...
Phase 6 - check inode connectivity...
        - resetting contents of realtime bitmap and summary inodes
        - traversing filesystem ...
        - agno = 0
        - agno = 1
        - agno = 2
        - agno = 3
        - traversal finished ...
        - moving disconnected inodes to lost+found ...
Phase 7 - verify and correct link counts...

        XFS_REPAIR Summary    Sat Feb 16 23:31:16 2008

Phase           Start           End             Duration
Phase 1:        02/16 23:31:10  02/16 23:31:10
Phase 2:        02/16 23:31:10  02/16 23:31:13  3 seconds
Phase 3:        02/16 23:31:13  02/16 23:31:15  2 seconds
Phase 4:        02/16 23:31:15  02/16 23:31:16  1 second
Phase 5:        02/16 23:31:16  02/16 23:31:16
Phase 6:        02/16 23:31:16  02/16 23:31:16
Phase 7:        02/16 23:31:16  02/16 23:31:16

Total run time: 6 seconds
done
# xfs_check local
# xfs_info /usr/local/
meta-data=/dev/mapper/system-local isize=256    agcount=4, agsize=131072
blks
         =                       sectsz=512   attr=2
data     =                       bsize=4096   blocks=524288, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096  
log      =internal               bsize=4096   blocks=32768, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0


I cannot confirm that wrong fdblocks count was not there before correction. I
checked FS's only after correction.


Cheers,

jan

-- 

Re: Differences in mkfs.xfs and xfs_info output.

[Jan Derfinak]

On Sat, 16 Feb 2008, Jan Derfinak wrote:

> I would like to ask if correcting the feature2 field can lead to this
> message?:
> # xfs_check /dev/system/mnt
> sb_fdblocks 190009, counted 191033
> sb_fdblocks 190009, aggregate AGF count 191033

I think no. I made some more test I think that wrong sb_fdblocks is
pertinent to lazy-count feature. I used mkfs.xfs patched with Eric's patch,
so there was no correction during mount.

# /root/mkfs.xfs -f /dev/loop0
meta-data=/dev/loop0             isize=256    agcount=4, agsize=64000 blks
         =                       sectsz=512   attr=2
data     =                       bsize=4096   blocks=256000, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096  
log      =internal log           bsize=4096   blocks=1200, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0
# xfs_check /dev/loop0
# mount /dev/loop0 /mnt/usb
# xfsrestore -J -f var.dump /mnt/usb
xfsrestore: using file dump (drive_simple) strategy
xfsrestore: version 2.2.48 (dump format 3.0) - Running single-threaded
xfsrestore: searching media for dump
xfsrestore: examining media file 0
xfsrestore: dump description: 
xfsrestore: hostname: host
xfsrestore: mount point: /var
xfsrestore: volume: /dev/mapper/system-var
xfsrestore: session time: Sun Feb 17 10:58:47 2008
xfsrestore: level: 0
xfsrestore: session label: "var"
xfsrestore: media label: "var"
xfsrestore: file system id: 6f9542f1-642f-463f-88ae-1b1b8b1383a9
xfsrestore: session id: 0cf809bb-a9f0-44aa-af7b-65fa79994677
xfsrestore: media id: b28bdc65-517e-4c27-809a-42a4baf3c238
xfsrestore: searching media for directory dump
xfsrestore: reading directories
xfsrestore: 1564 directories and 4965 entries processed
xfsrestore: directory post-processing
xfsrestore: restoring non-directory files
xfsrestore: restore complete: 50 seconds elapsed
xfsrestore: Restore Status: SUCCESS
# umount /mnt/usb
# xfs_check /dev/loop0
sb_fdblocks 48340, counted 49364


The same test without lazy-count.
# /root/mkfs.xfs -f -l lazy-count=0 /dev/loop0
meta-data=/dev/loop0             isize=256    agcount=4, agsize=64000 blks
         =                       sectsz=512   attr=2
data     =                       bsize=4096   blocks=256000, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096  
log      =internal log           bsize=4096   blocks=1200, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=0
realtime =none                   extsz=4096   blocks=0, rtextents=0
# xfs_check /dev/loop0
# mount /dev/loop0 /mnt/usb
# xfsrestore -J -f var.dump /mnt/usb
xfsrestore: using file dump (drive_simple) strategy
xfsrestore: version 2.2.48 (dump format 3.0) - Running single-threaded
.
.
.
xfsrestore: restore complete: 48 seconds elapsed
xfsrestore: Restore Status: SUCCESS
# umount /mnt/usb
# xfs_check /dev/loop0
#

No errors with lazy-count=0.

architecture: x86_64
kernel: SGI-XFS CVS-2008-02-16_08:00_UTC with ACLs, large block/inode numbers, no debug enabled
SGI XFS Quota Management subsystem
# /root/mkfs.xfs -V
mkfs.xfs version 2.9.6 (With Eric's feature2 patch)

Cheers,
 
jan

-- 

Re: Differences in mkfs.xfs and xfs_info output.

[David Chinner]

On Sat, Feb 16, 2008 at 11:41:42PM +0100, Jan Derfinak wrote:
> On Sat, 16 Feb 2008, David Chinner wrote:
> 
> > had time. The patch below should fix the problem - mkfs.xfs is writing
> > the features2 field to the wrong location in the superblock, and
> > this patch detects and corrects it. You'll probably see the output:
> 
> I would like to ask if correcting the feature2 field can lead to this
> message?:
> # xfs_check /dev/system/mnt
> sb_fdblocks 190009, counted 191033
> sb_fdblocks 190009, aggregate AGF count 191033

Lazy superblock counters mean that the superblock counters
are not kept exactly up to date at all times and hence this
can happen if the filesystem was not shut down cleanly. however,
when you remount the filesystem, it should recover all of the
correct values due to redundant information in the AGF and AGI
headers (that's the "aggregate AGF count" above). In the case
of a clean shutdown, however, they should be up to date.

Is this reproducable with simple tests? e.g. mkfs, mount, unmount
check? or doing some simple things like creating some files
with dd and rm'ing a subset of the files before unmounting?
I've run some simple tests this morning that do this, and I
don't see any issues. I'd like to confirm that simple cases
are working correctly on your test setup first...

Cheers,

Dave.
-- 
Dave Chinner
Principal Engineer
SGI Australian Software Group

Re: Differences in mkfs.xfs and xfs_info output.

[Jan Derfinak]

On Mon, 18 Feb 2008, David Chinner wrote:

> Is this reproducable with simple tests? e.g. mkfs, mount, unmount
> check? or doing some simple things like creating some files

mkfs, mount, xfsrestore, umount is 100% reproducable. I restored 5 different
filesystems, some of them several times.

Other tests (all show bug on first try):
# /root/mkfs.xfs -f /dev/loop0
meta-data=/dev/loop0             isize=256    agcount=4, agsize=64000 blks
         =                       sectsz=512   attr=2
data     =                       bsize=4096   blocks=256000, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096  
log      =internal log           bsize=4096   blocks=1200, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0
# mount /dev/loop0 /mnt/usb
# cp -a /mnt/mnt/xfs/xfs-cmds /mnt/usb  (xfs-cmds is CVS repository)
# umount /mnt/usb
# xfs_check /dev/loop0 
sb_fdblocks 248626, counted 249650

# /root/mkfs.xfs -f /dev/loop0
meta-data=/dev/loop0             isize=256    agcount=4, agsize=64000 blks
         =                       sectsz=512   attr=2
data     =                       bsize=4096   blocks=256000, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096  
log      =internal log           bsize=4096   blocks=1200, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0
# mount /dev/loop0 /mnt/usb
# cd /mnt/usb
# foreach i ( `seq 1 100` )
foreach? echo 123456789 > $i
foreach? end
# cd
# umount /mnt/usb
# xfs_check /dev/loop0
sb_fdblocks 253651, counted 254675

(added removing files)
# /root/mkfs.xfs -f /dev/loop0
meta-data=/dev/loop0             isize=256    agcount=4, agsize=64000 blks
         =                       sectsz=512   attr=2
data     =                       bsize=4096   blocks=256000, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096  
log      =internal log           bsize=4096   blocks=1200, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0
# mount /dev/loop0 /mnt/usb
# cd /mnt/usb
# foreach i ( `seq 1 100` )
foreach? echo 123456789 > $i
foreach? end
# foreach i ( `seq 1 2 100` )
foreach? rm -f $i
foreach? end
# cd
# umount /mnt/usb
# xfs_check /dev/loop0
sb_fdblocks 253701, counted 254725

(test if mount fixes fdblocks information)
# mount /dev/loop0 /mnt/usb
# umount /mnt/usb
# xfs_check /dev/loop0
sb_fdblocks 252677, counted 254725
# mount /dev/loop0 /mnt/usb
# umount /mnt/usb
# xfs_check /dev/loop0
sb_fdblocks 251653, counted 254725
# mount /dev/loop0 /mnt/usb
# umount /mnt/usb
# xfs_check /dev/loop0
sb_fdblocks 250629, counted 254725

mount, umount sequence changes sb_fdblocks without any activity on filesystem,
after every run is sb_fdblocks different (less than previous) but not correct.

# mount -V
mount (util-linux-ng 2.13-rc2)

fdblocks on fresh mkfs-ed filesystem is:
fdblocks = 254780

Should I do any specific test?

> with dd and rm'ing a subset of the files before unmounting?
> I've run some simple tests this morning that do this, and I
> don't see any issues. I'd like to confirm that simple cases

Did you use x86_64 and latest CVS kernel?

Cheers,

jan

-- 

Re: Differences in mkfs.xfs and xfs_info output.

[Jan Derfinak]

On Mon, 18 Feb 2008, Jan Derfinak wrote:

> > with dd and rm'ing a subset of the files before unmounting?
> > I've run some simple tests this morning that do this, and I
> > don't see any issues. I'd like to confirm that simple cases
> 
> Did you use x86_64 and latest CVS kernel?

I have run the mount,umount test on x86 architecture with the same kernel
source version. Kernel image is of course different, it is different
computer.
On x86 everything is ok.
I guess that problem is in 64-bit architecture. Is it possible?


dmesg:
SGI-XFS CVS-2008-02-15_08:00_UTC with ACLs, no debug enabled
SGI XFS Quota Management subsystem

mkfs.xfs version 2.9.6

# mkfs.xfs -f /dev/loop0
meta-data=/dev/loop0             isize=256    agcount=4, agsize=64000 blks
         =                       sectsz=512   attr=2
data     =                       bsize=4096   blocks=256000, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096  
log      =internal log           bsize=4096   blocks=1200, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0
# xfs_check /dev/loop0 
# mount /dev/loop0 /mnt/usb
# umount /dev/loop0 
# xfs_check /dev/loop0
# 


Cheers,
 
jan

-- 

Re: Differences in mkfs.xfs and xfs_info output.

[David Chinner]

On Tue, Feb 19, 2008 at 01:04:35AM +0100, Jan Derfinak wrote:
> On Mon, 18 Feb 2008, Jan Derfinak wrote:
> 
> > > with dd and rm'ing a subset of the files before unmounting?
> > > I've run some simple tests this morning that do this, and I
> > > don't see any issues. I'd like to confirm that simple cases
> > 
> > Did you use x86_64 and latest CVS kernel?
> 
> I have run the mount,umount test on x86 architecture with the same kernel
> source version. Kernel image is of course different, it is different
> computer.
> On x86 everything is ok.
> I guess that problem is in 64-bit architecture. Is it possible?

The output I showed you was from an ia64 machine, so it's not
purely 64bit related.

Can you rebuild you x86_64 kernel from the same kernel
tree you built the ia32 (make mrproper; make ....) and reinstall
it and see if the still exists?

Cheers,

Dave.
-- 
Dave Chinner
Principal Engineer
SGI Australian Software Group

Re: Differences in mkfs.xfs and xfs_info output.

[Jan Derfinak]

On Tue, 19 Feb 2008, David Chinner wrote:

> 
> The output I showed you was from an ia64 machine, so it's not
> purely 64bit related.
> 
> Can you rebuild you x86_64 kernel from the same kernel
> tree you built the ia32 (make mrproper; make ....) and reinstall
> it and see if the still exists?

Done, but the problem still exists.
# xfs_check /dev/loop0
sb_fdblocks 253756, counted 254780

Dave, when you tested on ia64, did you use mkfs.xfs which wrote feature2
record on right place or did you use your patch to correct feature2 on
mount? Because I use mkfs.xfs patched with Eric Sandeen patch on x86_64 to
create FS which really has lazy-count=1.

Cheers,
 
jan

-- 

Re: Differences in mkfs.xfs and xfs_info output.

[David Chinner]

On Tue, Feb 19, 2008 at 02:20:42AM +0100, Jan Derfinak wrote:
> On Tue, 19 Feb 2008, David Chinner wrote:
> 
> > 
> > The output I showed you was from an ia64 machine, so it's not
> > purely 64bit related.
> > 
> > Can you rebuild you x86_64 kernel from the same kernel
> > tree you built the ia32 (make mrproper; make ....) and reinstall
> > it and see if the still exists?
> 
> Done, but the problem still exists.
> # xfs_check /dev/loop0
> sb_fdblocks 253756, counted 254780
> 
> Dave, when you tested on ia64, did you use mkfs.xfs which wrote feature2
> record on right place or did you use your patch to correct feature2 on
> mount? Because I use mkfs.xfs patched with Eric Sandeen patch on x86_64 to
> create FS which really has lazy-count=1.

I did not use a patched mkfs - just my patch that does correction.
I think I need to test this on an x86_64 box and see if i can
reproduce it locally because it's not obviously operator error
or clearly an 32/64bit problem...

Cheers,

Dave.
-- 
Dave Chinner
Principal Engineer
SGI Australian Software Group

Re: Differences in mkfs.xfs and xfs_info output.

[Jan Derfinak]

On Tue, 19 Feb 2008, David Chinner wrote:

> I did not use a patched mkfs - just my patch that does correction.
> I think I need to test this on an x86_64 box and see if i can
> reproduce it locally because it's not obviously operator error
> or clearly an 32/64bit problem...

Ok. 
Will you have possibility to test it in near future or should I rather
recreate my FS's with lazy-count=0 to keep the data safe?

Maybe this information can be useful. Kernel and userspace tools were
compiled with:
# gcc -v
Using built-in specs.
Target: x86_64-suse-linux
Configured with: ../configure --enable-threads=posix --prefix=/usr
--with-local-prefix=/usr/local --infodir=/usr/share/info
--mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64
--enable-languages=c,c++,objc,fortran,obj-c++,java,ada
--enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.2.1
--enable-ssp --disable-libssp --disable-libgcj --with-slibdir=/lib64
--with-system-zlib --enable-shared --enable-__cxa_atexit
--enable-libstdcxx-allocator=new --disable-libstdcxx-pch
--program-suffix=-4.2 --enable-version-specific-runtime-libs
--without-system-libunwind --with-cpu=generic --host=x86_64-suse-linux
Thread model: posix
gcc version 4.2.1 (SUSE Linux)

Cheers,
 
jan


-- 

Re: Differences in mkfs.xfs and xfs_info output.

[Jan Derfinak]

On Tue, 19 Feb 2008, David Chinner wrote:

> I did not use a patched mkfs - just my patch that does correction.

I tried with only your patch. The result is slightly different, but
not correct.
# mkfs.xfs -f /dev/loop0 
meta-data=/dev/loop0             isize=256    agcount=4, agsize=64000 blks
         =                       sectsz=512   attr=2
data     =                       bsize=4096   blocks=256000, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096  
log      =internal log           bsize=4096   blocks=1200, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0
# mount /dev/loop0 /mnt/usb
# dmesg
...
Filesystem "loop0": Disabling barriers, not supported by the underlying device
XFS: correcting sb_features alignment problem
XFS mounting filesystem loop0
# umount /mnt/usb
# xfs_check  /dev/loop0
sb_fdblocks 253756, counted 254780
sb_fdblocks 253756, aggregate AGF count 254780


Cheers,
 
jan

-- 

Re: Differences in mkfs.xfs and xfs_info output.

[David Chinner]

On Tue, Feb 19, 2008 at 03:05:32PM +0100, Jan Derfinak wrote:
> On Tue, 19 Feb 2008, David Chinner wrote:
> 
> > I did not use a patched mkfs - just my patch that does correction.
> 
> I tried with only your patch. The result is slightly different, but
> not correct.

Ok, still 1024 blocks out. Still need to reproduce it locally.

FYI - thisis not a corruption bug - just an accounting problem.
IOWs, all it will cause is slightly premature detection of ENOSPC....

Cheers,

Dave.
-- 
Dave Chinner
Principal Engineer
SGI Australian Software Group

Re: Differences in mkfs.xfs and xfs_info output.

[Jan Derfinak]

On Wed, 20 Feb 2008, David Chinner wrote:

> On Tue, Feb 19, 2008 at 03:05:32PM +0100, Jan Derfinak wrote:
> > On Tue, 19 Feb 2008, David Chinner wrote:
> > 
> > > I did not use a patched mkfs - just my patch that does correction.
> > 
> > I tried with only your patch. The result is slightly different, but
> > not correct.
> 
> Ok, still 1024 blocks out. Still need to reproduce it locally.
> 
> FYI - thisis not a corruption bug - just an accounting problem.
> IOWs, all it will cause is slightly premature detection of ENOSPC....

Just for your information.
I tested kernel 2.6.25-rc5 compiled from sources from ftp.kernel.org.
The bug with wrong sb_fdblocks is there too:
# xfs_check /dev/system/mnt
# mount /mnt/mnt
# umount /mnt/mnt
# xfs_check /dev/system/mnt
sb_fdblocks 214009, counted 215033

# xfs_info /mnt/mnt
meta-data=/dev/mapper/system-mnt isize=256    agcount=4, agsize=554240 blks
         =                       sectsz=512   attr=2
data     =                       bsize=4096   blocks=2216960, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096  
log      =internal               bsize=4096   blocks=32768, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0
# uname -a
Linux host 2.6.25-rc5 #1 Sun Mar 16 21:17:39 CET 2008 x86_64 x86_64 x86_64 GNU/Linux
# xfs_repair -V
xfs_repair version 2.9.6


jan
 

-- 

Re: Differences in mkfs.xfs and xfs_info output.

[Jan Derfinak]

On Mon, 18 Feb 2008, David Chinner wrote:

> Is this reproducable with simple tests? e.g. mkfs, mount, unmount
> check? or doing some simple things like creating some files

One more test (no FS activity, only mount, umount sequence):
# /root/mkfs.xfs -f /dev/loop0
meta-data=/dev/loop0             isize=256    agcount=4, agsize=64000 blks
         =                       sectsz=512   attr=2
data     =                       bsize=4096   blocks=256000, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096  
log      =internal log           bsize=4096   blocks=1200, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0
# xfs_check /dev/loop0
# mount /dev/loop0 /mnt/usb
# umount /mnt/usb
# xfs_check /dev/loop0
sb_fdblocks 253756, counted 254780
# mount /dev/loop0 /mnt/usb
# umount /mnt/usb
# xfs_check /dev/loop0
sb_fdblocks 252732, counted 254780

Cheers,

jan

-- 

Re: Differences in mkfs.xfs and xfs_info output.

[David Chinner]

On Mon, Feb 18, 2008 at 01:17:21AM +0100, Jan Derfinak wrote:
> On Mon, 18 Feb 2008, David Chinner wrote:
> 
> > Is this reproducable with simple tests? e.g. mkfs, mount, unmount
> > check? or doing some simple things like creating some files
> 
> One more test (no FS activity, only mount, umount sequence):
> # /root/mkfs.xfs -f /dev/loop0
> meta-data=/dev/loop0             isize=256    agcount=4, agsize=64000 blks
>          =                       sectsz=512   attr=2
> data     =                       bsize=4096   blocks=256000, imaxpct=25
>          =                       sunit=0      swidth=0 blks
> naming   =version 2              bsize=4096  
> log      =internal log           bsize=4096   blocks=1200, version=2
>          =                       sectsz=512   sunit=0 blks, lazy-count=1
> realtime =none                   extsz=4096   blocks=0, rtextents=0
> # xfs_check /dev/loop0
> # mount /dev/loop0 /mnt/usb
> # umount /mnt/usb
> # xfs_check /dev/loop0
> sb_fdblocks 253756, counted 254780
> # mount /dev/loop0 /mnt/usb
> # umount /mnt/usb
> # xfs_check /dev/loop0
> sb_fdblocks 252732, counted 254780

It is clear that it is dropping by 1024 blocks per mount/unmount
sequence. That sounds like the reserved space for transactions at
ENOSPC not being put back in before the superblock is finally
written to disk on unmount. The reserved space defaults to 1024
blocks. Does your kernel tree have this code
in it in xfs_unmountfs():

   1272         /*
   1273          * Unreserve any blocks we have so that when we unmount we don't account
   1274          * the reserved free space as used. This is really only necessary for
   1275          * lazy superblock counting because it trusts the incore superblock
   1276          * counters to be aboslutely correct on clean unmount.
   1277          *
   1278          * We don't bother correcting this elsewhere for lazy superblock
   1279          * counting because on mount of an unclean filesystem we reconstruct the
   1280          * correct counter value and this is irrelevant.
   1281          *
   1282          * For non-lazy counter filesystems, this doesn't matter at all because
   1283          * we only every apply deltas to the superblock and hence the incore
   1284          * value does not matter....
   1285          */
   1286         resblks = 0;
   1287         xfs_reserve_blocks(mp, &resblks, NULL);


FWIW, i wonder if it has something to do with your /dev/loop0
setup. How have you set this up? Using a raw file and using
it for mkfs/mount/unmount/check does not show the problem:

$ sudo mkfs.xfs -d name=fs_file
meta-data=fs_file                isize=256    agcount=4, agsize=655424 blks
         =                       sectsz=512   attr=2
data     =                       bsize=4096   blocks=2621696, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096
log      =internal log           bsize=4096   blocks=2560, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0
$ sudo xfs_check -f ./fs_file
$ sudo mount -o loop fs_file /mnt/fred
$ sudo umount /mnt/fred
$ sudo xfs_check -f ./fs_file
$ sudo mount -o loop fs_file /mnt/fred
$ sudo umount /mnt/fred
$ sudo xfs_check -f ./fs_file
$

If you run your test on a similar setup, do you see the problem
still?

Cheers,

Dave.
-- 
Dave Chinner
Principal Engineer
SGI Australian Software Group

Re: Differences in mkfs.xfs and xfs_info output.

[ja]

On Mon, Feb 18, 2008 at 01:07:04PM +1100, David Chinner wrote:

> It is clear that it is dropping by 1024 blocks per mount/unmount
> sequence. That sounds like the reserved space for transactions at
> ENOSPC not being put back in before the superblock is finally
> written to disk on unmount. The reserved space defaults to 1024
> blocks. Does your kernel tree have this code
> in it in xfs_unmountfs():

Yes. I have the same code in xfs_mount.c.
In CVS/Entry I have 
/xfs_mount.c/1.417/Tue Feb  5 07:16:21 2008/-ko/

> FWIW, i wonder if it has something to do with your /dev/loop0
> setup. How have you set this up? Using a raw file and using
> it for mkfs/mount/unmount/check does not show the problem:

No, I restored filesystems on real partition (device mapper) with the same
result.

> If you run your test on a similar setup, do you see the problem
> still?

Yes.

# losetup -d /dev/loop0
# /root/mkfs.xfs -f -d name=test
meta-data=test                   isize=256    agcount=4, agsize=64000 blks
         =                       sectsz=512   attr=2
data     =                       bsize=4096   blocks=256000, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096  
log      =internal log           bsize=4096   blocks=1200, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0
# xfs_check -f ./test 
# mount -o loop test /mnt/usb
# umount /mnt/usb
# xfs_check -f ./test
sb_fdblocks 253756, counted 254780

Cheers,
 
jan