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 clea
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 w
I tried with only your patch. The result is slightly different, but not correct. meta-data=/dev/loop0 isize=256 agcount=4, agsize=64000 blks = sectsz=512 attr=2 data = bsize=4096 blocks=256000, imaxp
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.... Ch
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: sb_fdblocks 214009, counted 215033 meta-data=/dev/mapper/
Hello. I found following problem with xfs_info (xfs_grows -p xfs_info) command: meta-data=/dev/loop0 isize=256 agcount=4, agsize=32000 blks = sectsz=512 attr=2 data = bsize=4096 blocks=128000, imaxpc
... 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.... which is exactly what
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 k
..... .... 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 locatio
Thanks Eric and David. Yes, as I wrote in my mail architecture is x86_64. 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
I would like to ask if correcting the feature2 field can lead to this message?: sb_fdblocks 190009, counted 191033 sb_fdblocks 190009, aggregate AGF count 191033 "local" is copy (dd) of other correct
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. meta-data=/dev
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 remoun
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): meta-data=/dev/loop0 isize=256 agcount=4
One more test (no FS activity, only mount, umount sequence): meta-data=/dev/loop0 isize=256 agcount=4, agsize=64000 blks = sectsz=512 attr=2 data = bsize=4096 blocks=256000, imaxpct=25 = sunit=0 swid
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 writte
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/ No, I restored filesystems on real partition (device mapper) with the same result. Yes. m
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