On Mon, Sep 21, 2015 at 01:13:41PM +0200, Angelo Dureghello wrote: > Hi Dave, > > many thanks for the support. Sorry for the double mail, after > first registering mails was not accepted, so i re-registered > with a company mail. > > > On 19/09/2015 00:44, Dave Chinner wrote: > >On Fri, Sep 18, 2015 at 06:38:38PM +0200, Angelo Dureghello wrote: > >>Hi all, > >> > >>working on arm (32bit arch), kernel 4.1.6. > >Is this a new platform? > > > >Also, we need to know what compiler you are using, because we know > >that certain versions of gcc miscompile XFS kernel code on arm > >(4.6, 4.7 and certain versions of 4.8 are suspect) due to a > >combination of compiler mis-optimisations and kernel bugs in the > >arm 64 bit division asm implementation. > > > >As such, it would be worthwhile trying gcc-4.9 and a 4.3-rc1 kernel > >to see if the problems still occur. > > 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. > >>generic/009 [ 842.949643] run fstests generic/009 at 2015-09-18 > >>15:29:36 > >> - output mismatch (see > >>/home/angelo/xfstests/results//generic/009.out.bad) > >> --- tests/generic/009.out 2015-09-17 10:54:06.689071257 +0000 > >> +++ /home/angelo/xfstests/results//generic/009.out.bad > >>2015-09-18 15:29:41.412784177 +0000 > >> @@ -1,79 +1,45 @@ > >> QA output created by 009 > >> 1. into a hole > >> -0: [0..7]: hole > >> -1: [8..23]: unwritten > >> -2: [24..39]: hole > >> +0: [0..39]: hole > >> daa100df6e6711906b61c9ab5aa16032 > >> > >>also some other tests are giving the same bad notices. > >Can you attach the entire > >/home/angelo/xfstests/results//generic/009.out.bad file? I'm not > >sure which of the tests this output comes from, so I need to > >confirm which specific operations are resulting in errors. > Sure, i completed the whole generic + shared + xfs tests. > In total i have 38 errors. And trying now one by one to understand > the reason. > I attached the 009 output. > > >>-tests/generic/308 > >>------------------ .... > 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? 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 http://xfs.org/index.php/XFS_FAQ#Q:_What_information_should_I_include_when_reporting_a_problem.3F for details, and attach the (compressed) report file. Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
