Created attachment 113061 [details] Kernel log when remount and xfs_repair output. I tried to make XFS Filesystem with -d agcount=1 option. This setting is not recommended, but I need this to minimize filesystem space overhead. But, when I writes many files at once on extremely-small logsize filesystem and re-mount it, That says "can't read superblock". TO REPRODUCE: 1. Create image file. I used 4095MB, but same error occurs regardless of size. It occures on physical disks, too. 2. Create XFS filesystem on image. For minimize log size, I used following command: # mkfs.xfs -b size=512 -d agcount=1 -i maxpct=0 -l size=927b test_xfs 3. Mount this image to any location. I used following: # mount -o noatime,logbufs=8 test_xfs xfs_mount/ 4. Extract kernel source on it. I used following: # tar -xf linux-3.11.6.tar.xz --directory xfs_mount/ 5. When extraction is completed, unmount that image as soon as possible. 6. Try to mount that image. That says: mount: /dev/loop0: can't read superblock I'll attach Kernel log and output of xfs_repair. Here I tested with openSUSE 13.1 RC1, but same error occurs any distribution and vanilla kernels I checked. It occurs on 32bit x86, too. CentOS 5, 6 Ubuntu 11.04, 11.10, 12.04, 12.10 openSUSE 11.2, 11.3, 11.4, 12.1, 12.2, 12.3 Kernel 2.6.18, 2.6.28~39, Kernel 3.0, 3.1, 3.3, 3.4
It seems that problem can be avoided by : 1. Use large logsize. (with -l size=4096b, this case seems work on openSUSE 13.1 RC1.) 2. Use more agcount. (with agcount=2, this case seems work on openSUSE 13.1 RC1.) I think that it should work on extremely condition as I used because mkfs.xfs allows that parameters. And, it might be potentially occurs with larger log size and agcount.
> [148518.410860] attempt to access beyond end of device > [148518.410861] loop0: rw=32, want=18446744073709549309, limit=8386560 > [148518.410864] XFS (loop0): metadata I/O error: block 0xfffffffffffff6fb > ("xlog_bread_noalign") error 5 numblks 2 Interesting, so the block number went negative.
The dmesg also says: [848715.457943] XFS (loop3): Log size 927 blocks too small, minimum size is 4740 blocks [848715.465674] XFS (loop3): Log size out of supported range. Continuing onwards, but if log hangs are [848715.465674] experienced then please report this message in the bug report. Seems that at least mkfs & the kernel should agree on the minimum log size.
(In reply to Eric Sandeen from comment #3) > The dmesg also says: > > [848715.457943] XFS (loop3): Log size 927 blocks too small, minimum size is > 4740 blocks > [848715.465674] XFS (loop3): Log size out of supported range. Continuing > onwards, but if log hangs are > [848715.465674] experienced then please report this message in the bug > report. > > Seems that at least mkfs & the kernel should agree on the minimum log size. I can't see any messages such of that... mkfs.xfs done without errors, kernel doesn't complain about "log size" in my test environment, too. Is that system dependent? # uname -a Linux localhost 3.11.3-1-desktop #1 SMP PREEMPT Wed Oct 2 05:54:02 UTC 2013 (485f0d1) x86_64 x86_64 x86_64 GNU/Linux # mkfs.xfs -V mkfs.xfs version 3.1.11
(In reply to Eric Sandeen from comment #3) > The dmesg also says: > > [848715.457943] XFS (loop3): Log size 927 blocks too small, minimum size is > 4740 blocks > [848715.465674] XFS (loop3): Log size out of supported range. Continuing > onwards, but if log hangs are > [848715.465674] experienced then please report this message in the bug > report. > > Seems that at least mkfs & the kernel should agree on the minimum log size. Right now, I can see that message. It still occurs with very recent kernel, but it explains that log size under certain blocks does not officially supported. I'll check whether this error does not occur with 4740 or more blocks of log size, and close this issue when it does not occur with officially supported log size.
I'm batch-closing all xfs bugs which are more than 1 year old, sorry about that. If you still have this issue on a current kernel, please retest and re-open with this information. Thanks, -Eric
mkfs now enforces a minimum log size: # mkfs.xfs -m crc=0 -b size=512 -d agcount=1 -i maxpct=0 -l size=927b test_xfs log size 927 blocks too small, minimum size is 4800 blocks so with current code I don't think you'll see this sort of problem.