Hi Dave,

still thanks for following.

>> I am using actually gcc-linaro-4.9-2015.05-x86_64_arm-linux-gnueabihf
> So gcc-4.9 patched with a bunch of stuff from linaro and built as a
> cross compiler from x86-64 to 32 bit arm? ISTR we had a bunch of
> different compiler problems at one point that only showed up in
> kernels build with a x86-64 to arm cross-compiler.  In case you
> haven't guessed, XFS has a history of being bitten by ARM compiler
> problems. There's been a lot more problems in the past couple of
> years than the historical trend, though.
>
> As it is, I highly recommend that you try a current 4.3 kernel, as
> there are several code fixes in the XFS kernel code that work around
> compiler issues we know about. AFAIA, the do_div() asm bug that
> trips recent gcc optimisations isn't in the upstream kernel yet, but
> that can be worked around by setting CONFIG_CC_OPTIMIZE_FOR_SIZE=y
> in your build.

Well, i updated to this toolchain recently, but built the kernel also
with an i686 4.9 toolchain, and had exactly same tests errors.
Yes i am always cross compiling for armhf btw.
I am using a 4.1.5-rt from TI,
will try possibly some more recent version and let you know.

>> I have recent git version of xfstests, but generic/308 shows
>>
>> #! /bin/bash
>> # FS QA Test No. 308
>> #
>> # Regression test for commit:
>> # f17722f ext4: Fix max file size and logical block counting of
>> extent format file
> More that one filesystem had problems with maximum file sizes on 32
> bit systems. Compare the contents of the test; don't stop reading
> because the summary of the test makes you think the rest of the test
> is unrelated to the problem at hand.
>
>> I have a 16MB partition, and wondering why xfs allows from test 308
>> to create a 16TB file.
>>
>> -rw------- 1 root root  17592186044415 Sep 18 09:40 testfile.308
> https://en.wikipedia.org/wiki/Sparse_file
>
>> QA output created by 009
>> 	1. into a hole
>> 0: [0..39]: hole
>> daa100df6e6711906b61c9ab5aa16032
>> 	2. into allocated space
>> cc58a7417c2d7763adc45b6fcd3fa024
>> 	3. into unwritten space
>> daa100df6e6711906b61c9ab5aa16032
> I don't need to look any further to see that something is badly
> wrong here. This is telling me that no extents are being allocated
> at all, which indicates either fiemap is broken, awk/sed is
> broken or misbehaving (and hence mangling the output) or something
> deep in the filesystem code is fundamentally broken in some
> strange, silent way.
>
> Can you create an xfs filesystem on your scratch device, and
> manually run this command and post the output:
>
> # mkfs.xfs -V
> # mkfs.xfs <dev>
> # mount <dev> /mnt/xfs
> # xfs_io -f -c "pwrite 0 64k" -c sync \
> 	    -c "bmap -vp" -c "fiemap -v" \
> 	    -c "falloc 1024k 256k" -c sync \
> 	    -c "pwrite 1088k 64k" -c sync \
> 	    -c "bmap -vp" -c "fiemap -v" \
> 	    /mnt/xfs/testfile
>
> and attach the entire output?

I attached the output. I can be completely wrong, but file system
seems quite reliable for rootfs operations until now. At least,
never had any issue after installing and removing several and several
debian packages.
Only issues i had are created from test 308 that, if left running too long,
it damages the fs.

> It would also be good if you can run this command under trace-cmd
> and capture all the XFS events that occur during the test. See

Ok, about test 308, the 2 xfs_io operations passes, it stops on the rm 
exiting
the tests, while trying to erase the 16t file.

# Create a sparse file with an extent lays at one block before old 
s_maxbytes
offset=$(((2**32 - 2) * $block_size))
$XFS_IO_PROG -f -c "pwrite $offset $block_size" -c fsync $testfile 
 >$seqres.full 2>&1

rm can remove remove correctly this file (17592186040320)

# Write to the block after the extent just created
offset=$(((2**32 - 1) * $block_size))
$XFS_IO_PROG -f -c "pwrite $offset $block_size" -c fsync $testfile 
 >>$seqres.full 2>&1

while rm hangs on removing this file (17592186044415)

Magic sysrq l or t is not helping, nothing useful comes out.
But i collected the strace log. Since the issue is at unlinkat().



Many thanks
Best regards
Angelo


-- 
Best regards,
Angelo Dureghello