I created 1 GiB image file for test, and create XFS filesystem on it. # mkfs.xfs -b size=512 -d agcount=1 -i maxpct=0 -l size=262144b,lazy-cout=0 IMAGE When I try to extract linux 3.15 source tree on it, sometimes tar throws error such as: tar: linux-3.15/drivers/input/serio/hp_sdc_mlc.c: Cannot open: No space left on device tar: linux-3.15/drivers/input/mtd/ubi/upd.c: Cannot open: No space left on device tar: linux-3.15/drivers/input/pci/hotplug/cpci_hotplug.h: Cannot open: No space left on device tar: linux-3.15/drivers/input/regulator/da9052-regulator.c: Cannot open: No space left on device There's no any kernel report message. It occurs very randomly, sometimes it does not occur, sometimes it occurs with different file name or count. df result (skip some pseudo-filesystems): # df Filesystem 1K-blocks Used Available Use% Mounted on /dev/sda3 32373572 5399200 26974372 17% / /dev/loop0 917504 555434 362701 61% /root/TEST # uname -a Linux localhost 3.15.3-gentoo #5 SMP PREEMPT Tue Jul 8 16:55:03 KST 2014 x86_64 Intel(R) Core(TM) i5-2500S CPU @ 2.70GHz GenuineIntel GNU/Linux # mkfs.xfs -V mkfs.xfs version 3.1.11
Some additions: - df result on above message is result AFTER untarring kernel source, with error message described above. There's sufficient space for storing whole kernel source tree. That error message should not occur.
Please reproduce with mkfs default log and AG geometry. Using a single AG is not supported or recommended, and it is quite possibly the cause of the ENOSPC issue. i.e. # mkfs.xfs -b size=512 -i maxpct=0 -d file IMAGE -Dave.
Hmm... I can't reproduce it with 2 or more agcount several months... Can you explain why it occurs only with single AG? Is there any lock-related issue? I'm not XFS expert, but I think it should be work even single AG if it implemented correctly...
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