* xfstests, bad generic tests 009 and 308
@ 2015-09-18 16:38 Angelo Dureghello
2015-09-18 22:44 ` Dave Chinner
0 siblings, 1 reply; 14+ messages in thread
From: Angelo Dureghello @ 2015-09-18 16:38 UTC (permalink / raw)
To: xfs
Hi all,
working on arm (32bit arch), kernel 4.1.6.
Looking to find the reason of some bad results on xfstests,
-tests/generic/009
------------------
i get several "all holes" messages
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.
-tests/generic/308
------------------
I have now: CONFIG_LBDAF=y
In my target device this test creates a 16 Terabytes file 308.tempfile
-rw------- 1 root root 17592186044415 Sep 18 09:40 testfile.308
While "df" is not complaining about:
/dev/mmcblk0p5 8378368 45252 8333116 1% /media/p5
and next rm -f on it hands the cpu to 95%, forever.
This issue seems known from a long time, as it has been discussed in the
thread:
http://oss.sgi.com/archives/xfs/2013-04/msg00273.html
I was wondering if there was any special reason why the Jeff patch has
never been finally applied.
I applied this patch anyway, and tests pass.
--
Best regards,
Angelo Dureghello
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 14+ messages in thread* Re: xfstests, bad generic tests 009 and 308 2015-09-18 16:38 xfstests, bad generic tests 009 and 308 Angelo Dureghello @ 2015-09-18 22:44 ` Dave Chinner 2015-09-21 11:13 ` Angelo Dureghello 0 siblings, 1 reply; 14+ messages in thread From: Dave Chinner @ 2015-09-18 22:44 UTC (permalink / raw) To: Angelo Dureghello; +Cc: xfs 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. > Looking to find the reason of some bad results on xfstests, > > -tests/generic/009 > ------------------ > i get several "all holes" messages > > 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. > -tests/generic/308 > ------------------ > > I have now: CONFIG_LBDAF=y > > In my target device this test creates a 16 Terabytes file 308.tempfile > > -rw------- 1 root root 17592186044415 Sep 18 09:40 testfile.308 > > While "df" is not complaining about: > > /dev/mmcblk0p5 8378368 45252 8333116 1% /media/p5 > > and next rm -f on it hands the cpu to 95%, forever. > > This issue seems known from a long time, as it has been discussed in > the thread: > > http://oss.sgi.com/archives/xfs/2013-04/msg00273.html > > I was wondering if there was any special reason why the Jeff patch has > never been finally applied. MAX_LFS_FILESIZE on 32 bits is 8TB, whereas xfs supports 16TB file size on 32 bit systems. The specific issue this test fixed was committed in commit 8695d27 ("xfs: fix infinite loop at xfs_vm_writepage on 32bit system") http://oss.sgi.com/archives/xfs/2014-05/msg00447.html And, as you may notice now, generic/308 is the test case for the exact problem the above commit fixed. Can you find out exactly where the CPU is looping? sysrq-l will help, as will running 'perf top -U -g' to show you the hot code paths, and so on. Cheers, Dave. -- Dave Chinner david@fromorbit.com _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: xfstests, bad generic tests 009 and 308 2015-09-18 22:44 ` Dave Chinner @ 2015-09-21 11:13 ` Angelo Dureghello 2015-09-21 11:18 ` Angelo Dureghello 2015-09-21 22:52 ` Dave Chinner 0 siblings, 2 replies; 14+ messages in thread From: Angelo Dureghello @ 2015-09-21 11:13 UTC (permalink / raw) To: xfs [-- Attachment #1: Type: text/plain, Size: 4355 bytes --] 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 >> Looking to find the reason of some bad results on xfstests, >> >> -tests/generic/009 >> ------------------ >> i get several "all holes" messages >> >> 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 now: CONFIG_LBDAF=y >> >> In my target device this test creates a 16 Terabytes file 308.tempfile >> >> -rw------- 1 root root 17592186044415 Sep 18 09:40 testfile.308 >> >> While "df" is not complaining about: >> >> /dev/mmcblk0p5 8378368 45252 8333116 1% /media/p5 >> >> and next rm -f on it hands the cpu to 95%, forever. >> >> This issue seems known from a long time, as it has been discussed in >> the thread: >> >> http://oss.sgi.com/archives/xfs/2013-04/msg00273.html >> >> I was wondering if there was any special reason why the Jeff patch has >> never been finally applied. > MAX_LFS_FILESIZE on 32 bits is 8TB, whereas xfs supports 16TB file > size on 32 bit systems. The specific issue this test fixed was > committed in commit 8695d27 ("xfs: fix infinite loop at > xfs_vm_writepage on 32bit system") > > http://oss.sgi.com/archives/xfs/2014-05/msg00447.html > > And, as you may notice now, generic/308 is the test case for the > exact problem the above commit fixed. 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 > Can you find out exactly where the CPU is looping? sysrq-l will > help, as will running 'perf top -U -g' to show you the hot code > paths, and so on. Strangely, the patch http://oss.sgi.com/archives/xfs/2014-05/msg00447.html is already included in the xfs that comes with this 4.1.6 kernel, while only applying previous http://oss.sgi.com/archives/xfs/2013-04/msg00273.html patch from Jeff fix the issue and test 308 get passed. 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 When at 308 test exit, rm is invoked, system get blocked in infinite loop. root 5445 0.7 0.2 3760 3180 ttyS0 S+ 10:53 0:00 /bin/bash /home/angelo/xfstests/tests/generic/308 root 5674 100 0.0 1388 848 ttyS0 R+ 10:53 0:27 rm -f /media/p5/testfile.308 Can't install actually perf-tools for some debian repos issue, but let me know, i will enable sysrq if needed. Best regards Angelo > > Cheers, > > Dave. -- Best regards, Angelo Dureghello [-- Attachment #2: 009.out.bad --] [-- Type: text/plain, Size: 4743 bytes --] QA output created by 009 1. into a hole 0: [0..39]: hole daa100df6e6711906b61c9ab5aa16032 2. into allocated space cc58a7417c2d7763adc45b6fcd3fa024 3. into unwritten space daa100df6e6711906b61c9ab5aa16032 4. hole -> data 0: [0..39]: hole cc63069677939f69a6e8f68cae6a6dac 5. hole -> unwritten 0: [0..39]: hole daa100df6e6711906b61c9ab5aa16032 6. data -> hole 0: [24..39]: hole 1b3779878366498b28c702ef88c4a773 7. data -> unwritten 0: [32..39]: hole 1b3779878366498b28c702ef88c4a773 8. unwritten -> hole 0: [24..39]: hole daa100df6e6711906b61c9ab5aa16032 9. unwritten -> data 0: [32..39]: hole cc63069677939f69a6e8f68cae6a6dac 10. hole -> data -> hole 0: [0..39]: hole daa100df6e6711906b61c9ab5aa16032 11. data -> hole -> data f6aeca13ec49e5b266cd1c913cd726e3 12. unwritten -> data -> unwritten daa100df6e6711906b61c9ab5aa16032 13. data -> unwritten -> data f6aeca13ec49e5b266cd1c913cd726e3 14. data -> hole @ EOF e1f024eedd27ea6b1c3e9b841c850404 15. data -> hole @ 0 eecb7aa303d121835de05028751d301c 16. data -> cache cold ->hole eecb7aa303d121835de05028751d301c 17. data -> hole in single block file 0000000 cdcd cdcd cdcd cdcd cdcd cdcd cdcd cdcd * 0000200 0000 0000 0000 0000 0000 0000 0000 0000 * 0000400 cdcd cdcd cdcd cdcd cdcd cdcd cdcd cdcd * 1. into a hole 0: [0..39]: hole daa100df6e6711906b61c9ab5aa16032 2. into allocated space cc58a7417c2d7763adc45b6fcd3fa024 3. into unwritten space daa100df6e6711906b61c9ab5aa16032 4. hole -> data 0: [0..39]: hole cc63069677939f69a6e8f68cae6a6dac 5. hole -> unwritten 0: [0..39]: hole daa100df6e6711906b61c9ab5aa16032 6. data -> hole 0: [24..39]: hole 1b3779878366498b28c702ef88c4a773 7. data -> unwritten 0: [32..39]: hole 1b3779878366498b28c702ef88c4a773 8. unwritten -> hole 0: [24..39]: hole daa100df6e6711906b61c9ab5aa16032 9. unwritten -> data 0: [32..39]: hole cc63069677939f69a6e8f68cae6a6dac 10. hole -> data -> hole 0: [0..39]: hole daa100df6e6711906b61c9ab5aa16032 11. data -> hole -> data f6aeca13ec49e5b266cd1c913cd726e3 12. unwritten -> data -> unwritten daa100df6e6711906b61c9ab5aa16032 13. data -> unwritten -> data f6aeca13ec49e5b266cd1c913cd726e3 14. data -> hole @ EOF e1f024eedd27ea6b1c3e9b841c850404 15. data -> hole @ 0 eecb7aa303d121835de05028751d301c 16. data -> cache cold ->hole eecb7aa303d121835de05028751d301c 17. data -> hole in single block file 0000000 cdcd cdcd cdcd cdcd cdcd cdcd cdcd cdcd * 0000200 0000 0000 0000 0000 0000 0000 0000 0000 * 0000400 cdcd cdcd cdcd cdcd cdcd cdcd cdcd cdcd * 1. into a hole 0: [0..39]: hole daa100df6e6711906b61c9ab5aa16032 2. into allocated space cc58a7417c2d7763adc45b6fcd3fa024 3. into unwritten space cc58a7417c2d7763adc45b6fcd3fa024 4. hole -> data cc58a7417c2d7763adc45b6fcd3fa024 5. hole -> unwritten cc58a7417c2d7763adc45b6fcd3fa024 6. data -> hole cc58a7417c2d7763adc45b6fcd3fa024 7. data -> unwritten cc58a7417c2d7763adc45b6fcd3fa024 8. unwritten -> hole cc58a7417c2d7763adc45b6fcd3fa024 9. unwritten -> data cc58a7417c2d7763adc45b6fcd3fa024 10. hole -> data -> hole f6aeca13ec49e5b266cd1c913cd726e3 11. data -> hole -> data f6aeca13ec49e5b266cd1c913cd726e3 12. unwritten -> data -> unwritten f6aeca13ec49e5b266cd1c913cd726e3 13. data -> unwritten -> data f6aeca13ec49e5b266cd1c913cd726e3 14. data -> hole @ EOF e1f024eedd27ea6b1c3e9b841c850404 15. data -> hole @ 0 eecb7aa303d121835de05028751d301c 16. data -> cache cold ->hole eecb7aa303d121835de05028751d301c 17. data -> hole in single block file 0000000 cdcd cdcd cdcd cdcd cdcd cdcd cdcd cdcd * 0000200 0000 0000 0000 0000 0000 0000 0000 0000 * 0000400 cdcd cdcd cdcd cdcd cdcd cdcd cdcd cdcd * 1. into a hole 0: [0..39]: hole daa100df6e6711906b61c9ab5aa16032 2. into allocated space cc58a7417c2d7763adc45b6fcd3fa024 3. into unwritten space cc58a7417c2d7763adc45b6fcd3fa024 4. hole -> data cc58a7417c2d7763adc45b6fcd3fa024 5. hole -> unwritten cc58a7417c2d7763adc45b6fcd3fa024 6. data -> hole cc58a7417c2d7763adc45b6fcd3fa024 7. data -> unwritten cc58a7417c2d7763adc45b6fcd3fa024 8. unwritten -> hole cc58a7417c2d7763adc45b6fcd3fa024 9. unwritten -> data cc58a7417c2d7763adc45b6fcd3fa024 10. hole -> data -> hole f6aeca13ec49e5b266cd1c913cd726e3 11. data -> hole -> data f6aeca13ec49e5b266cd1c913cd726e3 12. unwritten -> data -> unwritten f6aeca13ec49e5b266cd1c913cd726e3 13. data -> unwritten -> data f6aeca13ec49e5b266cd1c913cd726e3 14. data -> hole @ EOF e1f024eedd27ea6b1c3e9b841c850404 15. data -> hole @ 0 eecb7aa303d121835de05028751d301c 16. data -> cache cold ->hole eecb7aa303d121835de05028751d301c 17. data -> hole in single block file 0000000 cdcd cdcd cdcd cdcd cdcd cdcd cdcd cdcd * 0000200 0000 0000 0000 0000 0000 0000 0000 0000 * 0000400 cdcd cdcd cdcd cdcd cdcd cdcd cdcd cdcd * [-- Attachment #3: Type: text/plain, Size: 121 bytes --] _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: xfstests, bad generic tests 009 and 308 2015-09-21 11:13 ` Angelo Dureghello @ 2015-09-21 11:18 ` Angelo Dureghello 2015-09-21 22:52 ` Dave Chinner 1 sibling, 0 replies; 14+ messages in thread From: Angelo Dureghello @ 2015-09-21 11:18 UTC (permalink / raw) To: xfs Sry, in my previous mail please s/16M/16G. Was a typo. I am using an SD card with test partitions 8G and 16G. Best regards Angelo On 21/09/2015 13:13, 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 > >>> Looking to find the reason of some bad results on xfstests, >>> >>> -tests/generic/009 >>> ------------------ >>> i get several "all holes" messages >>> >>> 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 now: CONFIG_LBDAF=y >>> >>> In my target device this test creates a 16 Terabytes file 308.tempfile >>> >>> -rw------- 1 root root 17592186044415 Sep 18 09:40 testfile.308 >>> >>> While "df" is not complaining about: >>> >>> /dev/mmcblk0p5 8378368 45252 8333116 1% /media/p5 >>> >>> and next rm -f on it hands the cpu to 95%, forever. >>> >>> This issue seems known from a long time, as it has been discussed in >>> the thread: >>> >>> http://oss.sgi.com/archives/xfs/2013-04/msg00273.html >>> >>> I was wondering if there was any special reason why the Jeff patch has >>> never been finally applied. >> MAX_LFS_FILESIZE on 32 bits is 8TB, whereas xfs supports 16TB file >> size on 32 bit systems. The specific issue this test fixed was >> committed in commit 8695d27 ("xfs: fix infinite loop at >> xfs_vm_writepage on 32bit system") >> >> http://oss.sgi.com/archives/xfs/2014-05/msg00447.html >> >> And, as you may notice now, generic/308 is the test case for the >> exact problem the above commit fixed. > > 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 > >> Can you find out exactly where the CPU is looping? sysrq-l will >> help, as will running 'perf top -U -g' to show you the hot code >> paths, and so on. > > Strangely, the patch > http://oss.sgi.com/archives/xfs/2014-05/msg00447.html is already included > in the xfs that comes with this 4.1.6 kernel, while only applying > previous > > http://oss.sgi.com/archives/xfs/2013-04/msg00273.html patch from Jeff > fix the issue and > test 308 get passed. > > > 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 > > > When at 308 test exit, rm is invoked, system get blocked in infinite > loop. > > root 5445 0.7 0.2 3760 3180 ttyS0 S+ 10:53 0:00 > /bin/bash /home/angelo/xfstests/tests/generic/308 > root 5674 100 0.0 1388 848 ttyS0 R+ 10:53 0:27 rm -f > /media/p5/testfile.308 > > Can't install actually perf-tools for some debian repos issue, but let > me know, i will enable sysrq > if needed. > > Best regards > Angelo > > >> >> Cheers, >> >> Dave. > > > > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs -- Best regards, Angelo Dureghello _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: xfstests, bad generic tests 009 and 308 2015-09-21 11:13 ` Angelo Dureghello 2015-09-21 11:18 ` Angelo Dureghello @ 2015-09-21 22:52 ` Dave Chinner 2015-09-22 12:41 ` Angelo Dureghello 2015-09-23 10:43 ` Yann Dupont - Veille Techno 1 sibling, 2 replies; 14+ messages in thread From: Dave Chinner @ 2015-09-21 22:52 UTC (permalink / raw) To: Angelo Dureghello; +Cc: xfs 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@fromorbit.com _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: xfstests, bad generic tests 009 and 308 2015-09-21 22:52 ` Dave Chinner @ 2015-09-22 12:41 ` Angelo Dureghello 2015-09-22 21:27 ` Dave Chinner 2015-09-23 10:43 ` Yann Dupont - Veille Techno 1 sibling, 1 reply; 14+ messages in thread From: Angelo Dureghello @ 2015-09-22 12:41 UTC (permalink / raw) To: xfs [-- Attachment #1: Type: text/plain, Size: 4187 bytes --] 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 [-- Attachment #2: mkfs_output.txt --] [-- Type: text/plain, Size: 2702 bytes --] root[249] ~ # mkfs.xfs -V mkfs.xfs version 3.2.1 root[250] ~ # mkfs.xfs /dev/mmcblk0p6 mkfs.xfs: /dev/mmcblk0p6 appears to contain an existing filesystem (xfs). mkfs.xfs: Use the -f option to force overwrite. root[251] ~ # mkfs.xfs -f /dev/mmcblk0p6 meta-data=/dev/mmcblk0p6 isize=256 agcount=4, agsize=551008 blks = sectsz=512 attr=2, projid32bit=1 = crc=0 finobt=0 data = bsize=4096 blocks=2204032, imaxpct=25 = sunit=0 swidth=0 blks naming =version 2 bsize=4096 ascii-ci=0 ftype=0 log =internal log bsize=4096 blocks=2560, version=2 = sectsz=512 sunit=0 blks, lazy-count=1 realtime =none extsz=4096 blocks=0, rtextents=0 root[252] ~ # mount /dev/mmcblk0p6 /media/p6 [38946.599770] XFS (mmcblk0p6): Mounting V4 Filesystem [38946.800708] XFS (mmcblk0p6): Ending clean mount # 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" \ /media/p6/testfile wrote 65536/65536 bytes at offset 0 64 KiB, 16 ops; 0.0000 sec (96.154 MiB/sec and 24615.3846 ops/sec) command "sync" not found /media/p6/testfile: EXT: FILE-OFFSET BLOCK-RANGE AG AG-OFFSET TOTAL FLAGS 0: [0..127]: 96..223 0 (96..223) 128 00000 /media/p6/testfile: EXT: FILE-OFFSET BLOCK-RANGE TOTAL FLAGS 0: [0..127]: 96..223 128 0x1 command "sync" not found wrote 65536/65536 bytes at offset 1114112 64 KiB, 16 ops; 0.0000 sec (112.208 MiB/sec and 28725.3142 ops/sec) command "sync" not found /media/p6/testfile: EXT: FILE-OFFSET BLOCK-RANGE AG AG-OFFSET TOTAL FLAGS 0: [0..127]: 96..223 0 (96..223) 128 00000 1: [128..2047]: hole 1920 2: [2048..2559]: 2144..2655 0 (2144..2655) 512 10000 /media/p6/testfile: EXT: FILE-OFFSET BLOCK-RANGE TOTAL FLAGS 0: [0..127]: 96..223 128 0x0 1: [128..2047]: hole 1920 2: [2048..2175]: 2144..2271 128 0x800 3: [2176..2303]: 2272..2399 128 0x0 4: [2304..2559]: 2400..2655 256 0x801 Step by step xfs_io ------------------- Due to the "sync" is missing, i tried also command by command with shell "sync" after each command. Output is exactly the same. [-- Attachment #3: strace_rm_308.txt --] [-- Type: text/plain, Size: 3618 bytes --] -rw------- 1 root root 17592186040320 Sep 22 10:55 testfile.308 rm ok -rw------- 1 root root 17592186044415 Sep 22 10:58 testfile.308 total 496 drwxr-xr-x 11 root root 4096 Sep 22 10:58 . drwxr-xr-x 4 root root 101 Sep 22 08:40 .. -rw------- 1 root root 131072 Sep 21 14:50 008.24410 -rw------- 1 root root 131072 Sep 21 14:52 008.2913 -rw------- 1 root root 4096 Sep 21 14:50 009.25001 -rw------- 1 root root 4096 Sep 21 14:52 009.3505 -rw------- 1 root root 81920 Sep 21 14:50 012.26531 -rw------- 1 root root 49152 Sep 21 14:52 012.5039 drwxr-xr-x 3 root root 4096 Sep 21 15:16 14536 drwxr-xr-x 3 root root 38 Sep 21 15:25 16802 drwxr-xr-x 3 root root 4096 Sep 21 15:26 18438 drwxr-xr-x 3 root root 38 Sep 21 15:27 21042 drwxr-xr-x 3 root root 38 Sep 21 14:50 27593 drwxr-xr-x 3 root root 70 Sep 21 15:08 8274 drwxr-xr-x 3 root root 15 Sep 21 14:53 fsstress.5653.1 drwxr-xr-x 22 root root 4096 Sep 21 14:53 fsstress.5653.2 -rw------- 1 root root 17592186044415 Sep 22 11:44 testfile.308 drwxr-xr-x 2 root root 20 Sep 21 15:12 tmp root[252] vpc24 /media/p5 # rm testfile.308 # strace rm testfile.308 execve("/bin/rm", ["rm", "testfile.308"], [/* 16 vars */]) = 0 brk(0) = 0x2a000 uname({sys="Linux", node="vpc24", ...}) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb6f36000 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=34089, ...}) = 0 mmap2(NULL, 34089, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb6f2d000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/lib/arm-linux-gnueabihf/libc.so.6", O_RDONLY|O_CLOEXEC) = 3 read(3, "\177ELF\1\1\1\3\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0Mw\1\0004\0\0\0"..., 512) = 512 lseek(3, 899996, SEEK_SET) = 899996 read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 2880) = 2880 lseek(3, 896548, SEEK_SET) = 896548 read(3, "A4\0\0\0aeabi\0\1*\0\0\0\0057-A\0\6\n\7A\10\1\t\2\n\3\f"..., 53) = 53 fstat64(3, {st_mode=S_IFREG|0755, st_size=902876, ...}) = 0 mmap2(NULL, 972200, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb6e23000 mprotect(0xb6efc000, 61440, PROT_NONE) = 0 mmap2(0xb6f0b000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xd8000) = 0xb6f0b000 mmap2(0xb6f0e000, 9640, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb6f0e000 close(3) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb6f2c000 set_tls(0xb6f2c850, 0xb6f39050, 0xb6f2cf38, 0xb6f2c850, 0xb6f39050) = 0 mprotect(0xb6f0b000, 8192, PROT_READ) = 0 mprotect(0x28000, 4096, PROT_READ) = 0 mprotect(0xb6f38000, 4096, PROT_READ) = 0 munmap(0xb6f2d000, 34089) = 0 brk(0) = 0x2a000 brk(0x4b000) = 0x4b000 ioctl(0, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS, {B115200 opost isig icanon echo ...}) = 0 newfstatat(AT_FDCWD, "testfile.308", {st_mode=S_IFREG|0600, st_size=17592186044415, ...}, AT_SYMLINK_NOFOLLOW) = 0 geteuid32() = 0 unlinkat(AT_FDCWD, "testfile.308", 0 [-- Attachment #4: Type: text/plain, Size: 121 bytes --] _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: xfstests, bad generic tests 009 and 308 2015-09-22 12:41 ` Angelo Dureghello @ 2015-09-22 21:27 ` Dave Chinner 2015-09-23 9:15 ` Angelo Dureghello 0 siblings, 1 reply; 14+ messages in thread From: Dave Chinner @ 2015-09-22 21:27 UTC (permalink / raw) To: Angelo Dureghello; +Cc: xfs On Tue, Sep 22, 2015 at 02:41:06PM +0200, Angelo Dureghello wrote: > >>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. Urk, the command should be "fsync", not "sync". Regardless, the last bmap/fiemap pair shows something interesting: bmap-vp: > /media/p6/testfile: > EXT: FILE-OFFSET BLOCK-RANGE AG AG-OFFSET TOTAL FLAGS > 0: [0..127]: 96..223 0 (96..223) 128 00000 > 1: [128..2047]: hole 1920 > 2: [2048..2559]: 2144..2655 0 (2144..2655) 512 10000 fiemap -v: > /media/p6/testfile: > EXT: FILE-OFFSET BLOCK-RANGE TOTAL FLAGS > 0: [0..127]: 96..223 128 0x0 > 1: [128..2047]: hole 1920 > 2: [2048..2175]: 2144..2271 128 0x800 > 3: [2176..2303]: 2272..2399 128 0x0 > 4: [2304..2559]: 2400..2655 256 0x801 Note that they are different - the former shows an unwritten extent of 256k @ offset 1MB, the later shows that extent split by 64k of data @ 1088k. The bmap -vp output is incorrect - it is supposed to sync data first and so should look the same as the fiemap output. Can you run this test again, this time with s/sync/fsync so the files are clean when bmap/fiemap are run? Can you run it a second time (umount/mkfs again) but with fiemap run first? i.e '-c "fiemap -v" -c "bmap -vp" \' instead of the original order? Next, can you compile your kernel with CONFIG_XFS_DEBUG=y and rerun the tests? Does anything interesting appear in dmesg during the test run? > 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. right, normal distro operation doesn't use preallocation or hole punching, so you won't have seen issues with that. > 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) What is the large number here? offset: (2**32 - 2) * 4096 = 17592186036224 end file size: (2**32 - 2) * 4096 + 4096 = 17592186040320 So it is the end file size. > # 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 This should fail with -EFBIG > while rm hangs on removing this file (17592186044415) offset: (2**32 - 1) * 4096 = 17592186040320 end file size: (2**32 - 1) * 4096 + 4096 = 17592186044416 Hmmm - that file is truncated by one byte. We set sb->s_maxbytes to 17592186044415 in xfs_max_file_offset() on 32 bit systems, so this truncation is expected. Most definitely need to run this under CONFIG_XFS_DEBUG=y - you should enable this whenever running xfstests to check things are working correctly as it enables all sorts of internal consistency and constraint checking (i.e. checking things that "should never, ever happen" haven't actually occurred). > Magic sysrq l or t is not helping, nothing useful comes out. > But i collected the strace log. Since the issue is at unlinkat(). Not actually useful - I need to know what is happening inside the unlinkat() call. I'm going to need a trace-cmd event dump of that xfs_io command and the subsequent rm (at least for the first couple of seconds of the rm). Please put the output file from the trace-cmd record command on a tmpfs filesystem so it doesn't pollute the xfs event trace ;) Cheers, Dave. -- Dave Chinner david@fromorbit.com _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: xfstests, bad generic tests 009 and 308 2015-09-22 21:27 ` Dave Chinner @ 2015-09-23 9:15 ` Angelo Dureghello 2015-09-23 22:25 ` Dave Chinner 0 siblings, 1 reply; 14+ messages in thread From: Angelo Dureghello @ 2015-09-23 9:15 UTC (permalink / raw) To: xfs [-- Attachment #1: Type: text/plain, Size: 2888 bytes --] Hi Dave, many thanks. On 22/09/2015 23:27, Dave Chinner wrote: > Urk, the command should be "fsync", not "sync". Regardless, the > last bmap/fiemap pair shows something interesting: > > bmap-vp: > >> /media/p6/testfile: >> EXT: FILE-OFFSET BLOCK-RANGE AG AG-OFFSET TOTAL FLAGS >> 0: [0..127]: 96..223 0 (96..223) 128 00000 >> 1: [128..2047]: hole 1920 >> 2: [2048..2559]: 2144..2655 0 (2144..2655) 512 10000 > fiemap -v: > >> /media/p6/testfile: >> EXT: FILE-OFFSET BLOCK-RANGE TOTAL FLAGS >> 0: [0..127]: 96..223 128 0x0 >> 1: [128..2047]: hole 1920 >> 2: [2048..2175]: 2144..2271 128 0x800 >> 3: [2176..2303]: 2272..2399 128 0x0 >> 4: [2304..2559]: 2400..2655 256 0x801 > Note that they are different - the former shows an unwritten extent > of 256k @ offset 1MB, the later shows that extent split by 64k of > data @ 1088k. > > The bmap -vp output is incorrect - it is supposed to sync data first > and so should look the same as the fiemap output. Can you run this > test again, this time with s/sync/fsync so the files are clean when > bmap/fiemap are run? Can you run it a second time (umount/mkfs > again) but with fiemap run first? i.e '-c "fiemap -v" -c "bmap -vp" \' > instead of the original order? > > Next, can you compile your kernel with CONFIG_XFS_DEBUG=y and rerun > the tests? Does anything interesting appear in dmesg during the test > run? Done, see mkfs_output_2.txt attached > Not actually useful - I need to know what is happening inside the > unlinkat() call. I'm going to need a trace-cmd event dump of that > xfs_io command and the subsequent rm (at least for the first couple > of seconds of the rm). Please put the output file from the trace-cmd > record command on a tmpfs filesystem so it doesn't pollute the xfs > event trace ;) > I set some traces inside fs/namei.c do_unlinkat() root[243] vpc24 (master) /home/angelo/xfstests # ./start_xfs_test.sh QA output created by 308 [ 144.822616] XFS (mmcblk0p5): Mounting V4 Filesystem [ 145.074537] XFS (mmcblk0p5): Starting recovery (logdev: internal) [ 145.107298] XFS (mmcblk0p5): Ending recovery (logdev: internal) Silence is golden [ 145.413606] do_unlinkat(): entering [ 145.417124] do_unlinkat(): retry [ 145.421156] do_unlinkat(): retry_delegate [ 145.425920] do_unlinkat(): vfs_unlink returns 0 [ 145.430950] do_unlinkat(): exit2 At least that function "seems" to complete, but, as from my previous message looks like strace was not showing nothig over it. I captured about 10 seconds of events after the "hang" on 308. Hope they are enough. File is quite long, so you can read it from here: http://sysam.it/~angelo/events.txt bye, -- Best regards, Angelo Dureghello [-- Attachment #2: mkfs_output_2.txt --] [-- Type: text/plain, Size: 4048 bytes --] # # xfs_io -f -c "pwrite 0 64k" -c fsync \ -c "bmap -vp" -c "fiemap -v" \ -c "falloc 1024k 256k" -c fsync \ -c "pwrite 1088k 64k" -c fsync \ -c "bmap -vp" -c "fiemap -v" \ /media/p6/testfile # xfs_io -f -c "pwrite 0 64k" -c fsync \ > -c "bmap -vp" -c "fiemap -v" \ > -c "falloc 1024k 256k" -c fsync \ > -c "pwrite 1088k 64k" -c fsync \ > -c "bmap -vp" -c "fiemap -v" \ > /media/p6/testfile wrote 65536/65536 bytes at offset 0 64 KiB, 16 ops; 0.0000 sec (10.271 MiB/sec and 2629.4166 ops/sec) /media/p6/testfile: EXT: FILE-OFFSET BLOCK-RANGE AG AG-OFFSET TOTAL FLAGS 0: [0..127]: 96..223 0 (96..223) 128 00000 /media/p6/testfile: EXT: FILE-OFFSET BLOCK-RANGE TOTAL FLAGS 0: [0..127]: 96..223 128 0x1 wrote 65536/65536 bytes at offset 1114112 64 KiB, 16 ops; 0.0000 sec (11.857 MiB/sec and 3035.4771 ops/sec) /media/p6/testfile: EXT: FILE-OFFSET BLOCK-RANGE AG AG-OFFSET TOTAL FLAGS 0: [0..127]: 96..223 0 (96..223) 128 00000 1: [128..2047]: hole 1920 2: [2048..2175]: 2144..2271 0 (2144..2271) 128 10000 3: [2176..2303]: 2272..2399 0 (2272..2399) 128 00000 4: [2304..2559]: 2400..2655 0 (2400..2655) 256 10000 /media/p6/testfile: EXT: FILE-OFFSET BLOCK-RANGE TOTAL FLAGS 0: [0..127]: 96..223 128 0x0 1: [128..2047]: hole 1920 2: [2048..2175]: 2144..2271 128 0x800 3: [2176..2303]: 2272..2399 128 0x0 4: [2304..2559]: 2400..2655 256 0x801 root[251] host ~ # mkfs.xfs -f /dev/mmcblk0p6 meta-data=/dev/mmcblk0p6 isize=256 agcount=4, agsize=551008 blks = sectsz=512 attr=2, projid32bit=1 = crc=0 finobt=0 data = bsize=4096 blocks=2204032, imaxpct=25 = sunit=0 swidth=0 blks naming =version 2 bsize=4096 ascii-ci=0 ftype=0 log =internal log bsize=4096 blocks=2560, version=2 = sectsz=512 sunit=0 blks, lazy-count=1 realtime =none extsz=4096 blocks=0, rtextents=0 root[252] host ~ # mount /dev/mmcblk0p6 /media/p6 [ 1000.531021] XFS (mmcblk0p6): Mounting V4 Filesystem [ 1000.813339] XFS (mmcblk0p6): Ending clean mount root[253] host ~ # xfs_io -f -c "pwrite 0 64k" -c fsync \ > -c "bmap -vp" -c "fiemap -v" \ > -c "falloc 1024k 256k" -c fsync \ > -c "pwrite 1088k 64k" -c fsync \ > -c "fiemap -v" -c "bmap -vp" \ > /media/p6/testfile wrote 65536/65536 bytes at offset 0 64 KiB, 16 ops; 0.0000 sec (10.126 MiB/sec and 2592.3526 ops/sec) /media/p6/testfile: EXT: FILE-OFFSET BLOCK-RANGE AG AG-OFFSET TOTAL FLAGS 0: [0..127]: 96..223 0 (96..223) 128 00000 /media/p6/testfile: EXT: FILE-OFFSET BLOCK-RANGE TOTAL FLAGS 0: [0..127]: 96..223 128 0x1 wrote 65536/65536 bytes at offset 1114112 64 KiB, 16 ops; 0.0000 sec (11.519 MiB/sec and 2948.7652 ops/sec) /media/p6/testfile: EXT: FILE-OFFSET BLOCK-RANGE TOTAL FLAGS 0: [0..127]: 96..223 128 0x0 1: [128..2047]: hole 1920 2: [2048..2175]: 2144..2271 128 0x800 3: [2176..2303]: 2272..2399 128 0x0 4: [2304..2559]: 2400..2655 256 0x801 /media/p6/testfile: EXT: FILE-OFFSET BLOCK-RANGE AG AG-OFFSET TOTAL FLAGS 0: [0..127]: 96..223 0 (96..223) 128 00000 1: [128..2047]: hole 1920 2: [2048..2175]: 2144..2271 0 (2144..2271) 128 10000 3: [2176..2303]: 2272..2399 0 (2272..2399) 128 00000 4: [2304..2559]: 2400..2655 0 (2400..2655) 256 10000 root[254] host ~ [-- Attachment #3: Type: text/plain, Size: 121 bytes --] _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: xfstests, bad generic tests 009 and 308 2015-09-23 9:15 ` Angelo Dureghello @ 2015-09-23 22:25 ` Dave Chinner 0 siblings, 0 replies; 14+ messages in thread From: Dave Chinner @ 2015-09-23 22:25 UTC (permalink / raw) To: Angelo Dureghello; +Cc: xfs On Wed, Sep 23, 2015 at 11:15:28AM +0200, Angelo Dureghello wrote: > Hi Dave, > > many thanks. > > On 22/09/2015 23:27, Dave Chinner wrote: > >Urk, the command should be "fsync", not "sync". Regardless, the > >last bmap/fiemap pair shows something interesting: > > > >bmap-vp: > > > >>/media/p6/testfile: > >> EXT: FILE-OFFSET BLOCK-RANGE AG AG-OFFSET TOTAL FLAGS > >> 0: [0..127]: 96..223 0 (96..223) 128 00000 > >> 1: [128..2047]: hole 1920 > >> 2: [2048..2559]: 2144..2655 0 (2144..2655) 512 10000 > >fiemap -v: .... > >and so should look the same as the fiemap output. Can you run this > >test again, this time with s/sync/fsync so the files are clean when Ok, so a preceding fsync results in bmap displaying all data ranges being written. Hmmm - I'll need to look into that, it's likely not a problem but just a longstanding bmap wart that fiemap doesn't have... > >Next, can you compile your kernel with CONFIG_XFS_DEBUG=y and rerun > >the tests? Does anything interesting appear in dmesg during the test > >run? Nothing in dmesg? > >Not actually useful - I need to know what is happening inside the > >unlinkat() call. I'm going to need a trace-cmd event dump of that > >xfs_io command and the subsequent rm (at least for the first couple > >of seconds of the rm). Please put the output file from the trace-cmd > >record command on a tmpfs filesystem so it doesn't pollute the xfs > >event trace ;) > > > I set some traces inside fs/namei.c do_unlinkat() > > root[243] vpc24 (master) /home/angelo/xfstests > # ./start_xfs_test.sh > QA output created by 308 > [ 144.822616] XFS (mmcblk0p5): Mounting V4 Filesystem > [ 145.074537] XFS (mmcblk0p5): Starting recovery (logdev: internal) > [ 145.107298] XFS (mmcblk0p5): Ending recovery (logdev: internal) > Silence is golden > [ 145.413606] do_unlinkat(): entering > [ 145.417124] do_unlinkat(): retry > [ 145.421156] do_unlinkat(): retry_delegate > [ 145.425920] do_unlinkat(): vfs_unlink returns 0 > [ 145.430950] do_unlinkat(): exit2 I think you'll find it's the deferred __fput() run from task_work_run() that does all the work of freeing the extents in the file. task_work_run() is executed before the process returns to userspace.... > At least that function "seems" to complete, but, as from my previous > message > looks like strace was not showing nothig over it. > > I captured about 10 seconds of events after the "hang" on 308. Hope > they are > enough. I need to see the events that lead up to the hang, so you need to start tracing before you run the test script, then stop tracing once the hang has occurred. If the trace doesn't have events from the processes the test runs, then you haven't captured the right events... Cheers, Dave. -- Dave Chinner david@fromorbit.com _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: xfstests, bad generic tests 009 and 308 2015-09-21 22:52 ` Dave Chinner 2015-09-22 12:41 ` Angelo Dureghello @ 2015-09-23 10:43 ` Yann Dupont - Veille Techno 2015-09-23 22:04 ` Dave Chinner 1 sibling, 1 reply; 14+ messages in thread From: Yann Dupont - Veille Techno @ 2015-09-23 10:43 UTC (permalink / raw) To: xfs Le 22/09/2015 00:52, Dave Chinner a écrit : > 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. Hi dave, I can confirm that CONFIG_CC_OPTIMIZE_FOR_SIZE=y is (was ?) the only way for me to have reliable XFS kernel code on different arm platforms (Marvell kirkwood, Allwinner A20, Amlogic S805), no matter what recent gcc version I've been using. I must admit I was cross-compiling from X86-64 too, but I think (not sure) that it was also the case with native gcc. I must also admit that I didn't tried since some months, because CONFIG_CC_OPTIMIZE_FOR_SIZE=y was the silver bullet for arm xfs kernel crashes. This crash was difficult to understand because it occurs quite randomly (I.e it can take several hours to trigger) If there's a patch floating around for gcc (or kernel), I'm interested to test. Cheers, _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: xfstests, bad generic tests 009 and 308 2015-09-23 10:43 ` Yann Dupont - Veille Techno @ 2015-09-23 22:04 ` Dave Chinner 2015-09-24 8:20 ` Yann Dupont - Veille Techno 0 siblings, 1 reply; 14+ messages in thread From: Dave Chinner @ 2015-09-23 22:04 UTC (permalink / raw) To: Yann Dupont - Veille Techno; +Cc: xfs On Wed, Sep 23, 2015 at 12:43:21PM +0200, Yann Dupont - Veille Techno wrote: > Le 22/09/2015 00:52, Dave Chinner a écrit : > >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. > > Hi dave, > > I can confirm that CONFIG_CC_OPTIMIZE_FOR_SIZE=y is (was ?) the only > way for me to have reliable XFS kernel code on different arm > platforms (Marvell kirkwood, Allwinner A20, Amlogic S805), no matter > what recent gcc version I've been using. > > I must admit I was cross-compiling from X86-64 too, but I think (not > sure) that it was also the case with native gcc. > > I must also admit that I didn't tried since some months, because > CONFIG_CC_OPTIMIZE_FOR_SIZE=y was the silver bullet for arm xfs > kernel crashes. This crash was difficult to understand because it > occurs quite randomly (I.e it can take several hours to trigger) > > If there's a patch floating around for gcc (or kernel), I'm > interested to test. See this subthread from august: http://oss.sgi.com/archives/xfs/2015-08/msg00234.html AFAICT, the do_div patch to fix the problem has not yet been picked up - it's not in the 4.3-rc2 kernel... Cheers, Dave. -- Dave Chinner david@fromorbit.com _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: xfstests, bad generic tests 009 and 308 2015-09-23 22:04 ` Dave Chinner @ 2015-09-24 8:20 ` Yann Dupont - Veille Techno 2015-09-27 0:40 ` Angelo Dureghello 0 siblings, 1 reply; 14+ messages in thread From: Yann Dupont - Veille Techno @ 2015-09-24 8:20 UTC (permalink / raw) To: Dave Chinner; +Cc: xfs Le 24/09/2015 00:04, Dave Chinner a écrit : > On Wed, Sep 23, 2015 at 12:43:21PM +0200, Yann Dupont - Veille Techno wrote: >> Le 22/09/2015 00:52, Dave Chinner a écrit : >>> 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. >> Hi dave, >> >> I can confirm that CONFIG_CC_OPTIMIZE_FOR_SIZE=y is (was ?) the only >> way for me to have reliable XFS kernel code on different arm >> platforms (Marvell kirkwood, Allwinner A20, Amlogic S805), no matter >> what recent gcc version I've been using. >> >> I must admit I was cross-compiling from X86-64 too, but I think (not >> sure) that it was also the case with native gcc. >> >> I must also admit that I didn't tried since some months, because >> CONFIG_CC_OPTIMIZE_FOR_SIZE=y was the silver bullet for arm xfs >> kernel crashes. This crash was difficult to understand because it >> occurs quite randomly (I.e it can take several hours to trigger) >> >> If there's a patch floating around for gcc (or kernel), I'm >> interested to test. > See this subthread from august: > > http://oss.sgi.com/archives/xfs/2015-08/msg00234.html Oh, missed this thread. Thanks a lot for the pointer, will try this patch ! Cheers, _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: xfstests, bad generic tests 009 and 308 2015-09-24 8:20 ` Yann Dupont - Veille Techno @ 2015-09-27 0:40 ` Angelo Dureghello 0 siblings, 0 replies; 14+ messages in thread From: Angelo Dureghello @ 2015-09-27 0:40 UTC (permalink / raw) To: xfs [-- Attachment #1: Type: text/plain, Size: 2414 bytes --] Hi Dave and all, The 99% cpu loop on tests/generic/308 (on "rm") happens also on i686 (32bit), kernel 4.2.0 (gcc 4.9.1) So, we can exclude it is a cross-compilation issue, or an ARM specific issue. It should just be a 32-bit rch wide related issue. I hardly found out the reason, at my opinion it doesn't have to be fixed in xfs. I proposed this patch. http://marc.info/?l=linux-kernel&m=144330858305518&w=2 Let's see if the list reply. Couldn't proceed still on the other "all hole" errors, will look into that. As far as i know, tests as 009 seems to give same errors to non arm users too. Will investigate further. Best regards, Angelo Dureghello On 24/09/2015 10:20, Yann Dupont - Veille Techno wrote: > Le 24/09/2015 00:04, Dave Chinner a écrit : >> On Wed, Sep 23, 2015 at 12:43:21PM +0200, Yann Dupont - Veille Techno >> wrote: >>> Le 22/09/2015 00:52, Dave Chinner a écrit : >>>> 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. >>> Hi dave, >>> >>> I can confirm that CONFIG_CC_OPTIMIZE_FOR_SIZE=y is (was ?) the only >>> way for me to have reliable XFS kernel code on different arm >>> platforms (Marvell kirkwood, Allwinner A20, Amlogic S805), no matter >>> what recent gcc version I've been using. >>> >>> I must admit I was cross-compiling from X86-64 too, but I think (not >>> sure) that it was also the case with native gcc. >>> >>> I must also admit that I didn't tried since some months, because >>> CONFIG_CC_OPTIMIZE_FOR_SIZE=y was the silver bullet for arm xfs >>> kernel crashes. This crash was difficult to understand because it >>> occurs quite randomly (I.e it can take several hours to trigger) >>> >>> If there's a patch floating around for gcc (or kernel), I'm >>> interested to test. >> See this subthread from august: >> >> http://oss.sgi.com/archives/xfs/2015-08/msg00234.html > > Oh, missed this thread. > > Thanks a lot for the pointer, will try this patch ! > Cheers, > > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs -- Best regards, Angelo Dureghello [-- Attachment #2: ftrace_rm_308.txt --] [-- Type: text/plain, Size: 15971 bytes --] # cat /sys/kernel/debug/tracing/trace | head -1000 # tracer: function_graph # # CPU DURATION FUNCTION CALLS # | | | | | | | 1) 0.814 us | xfs_file_open(); 0) | xfs_xattr_get() { 0) 0.650 us | xfs_attr_get(); 0) 5.856 us | } 0) | xfs_file_read_iter() { 0) 1.301 us | xfs_ilock(); 0) 1.139 us | xfs_iunlock(); 0) + 19.032 us | } 0) | xfs_file_read_iter() { 0) 0.814 us | xfs_ilock(); 0) 0.813 us | xfs_iunlock(); 0) + 15.942 us | } 0) | xfs_file_read_iter() { 0) 0.488 us | xfs_ilock(); 0) 0.813 us | xfs_iunlock(); 0) + 12.363 us | } 0) | xfs_vn_follow_link() { 0) | xfs_readlink() { 0) 0.814 us | xfs_ilock(); 0) 0.651 us | xfs_iunlock(); 0) 9.109 us | } 0) + 14.315 us | } 0) 0.488 us | xfs_file_open(); 0) | xfs_file_read_iter() { 0) 0.813 us | xfs_ilock(); 0) 0.814 us | xfs_iunlock(); 0) + 13.501 us | } 0) | xfs_file_read_iter() { 0) 0.651 us | xfs_ilock(); 0) 0.651 us | xfs_iunlock(); 0) + 12.200 us | } 0) 0.976 us | xfs_file_mmap(); 0) 0.651 us | xfs_file_mmap(); 0) | xfs_filemap_fault() { 0) 0.813 us | xfs_ilock(); 0) 0.813 us | xfs_iunlock(); 0) + 11.550 us | } 0) 0.813 us | xfs_file_mmap(); 0) 0.813 us | xfs_file_mmap(); 0) | xfs_filemap_fault() { 0) 0.813 us | xfs_ilock(); 0) 0.651 us | xfs_iunlock(); 0) + 10.410 us | } 0) | xfs_file_release() { 0) | xfs_release() { 0) 0.650 us | xfs_can_free_eofblocks(); 0) | xfs_free_eofblocks() { 0) 0.976 us | xfs_ilock(); 0) | xfs_bmapi_read() { 0) 0.488 us | xfs_isilocked(); 0) | xfs_bmap_search_extents() { 0) | xfs_bmap_search_multi_extents() { 0) | xfs_iext_bno_to_ext() { 0) 0.326 us | xfs_bmbt_get_startoff(); 0) 0.650 us | xfs_bmbt_get_blockcount(); 0) + 76.291 us | } 0) 0.488 us | xfs_iext_get_ext(); 0) | xfs_bmbt_get_all() { 0) 0.488 us | __xfs_bmbt_get_all(); 0) 4.067 us | } 0) + 92.070 us | } 0) + 95.648 us | } 0) ! 104.270 us | } 0) 0.650 us | xfs_iunlock(); 0) ! 117.608 us | } 0) ! 128.832 us | } 0) ! 132.899 us | } 0) | xfs_file_release() { 0) | xfs_release() { 0) 0.651 us | xfs_can_free_eofblocks(); 0) | xfs_free_eofblocks() { 0) 0.976 us | xfs_ilock(); 0) | xfs_bmapi_read() { 0) 0.325 us | xfs_isilocked(); 0) | xfs_bmap_search_extents() { 0) | xfs_bmap_search_multi_extents() { 0) | xfs_iext_bno_to_ext() { 0) 0.325 us | xfs_bmbt_get_startoff(); 0) 0.326 us | xfs_bmbt_get_blockcount(); 0) 7.808 us | } 0) 0.488 us | xfs_iext_get_ext(); 0) | xfs_bmbt_get_all() { 0) 0.488 us | __xfs_bmbt_get_all(); 0) 4.067 us | } 0) + 22.286 us | } 0) + 26.027 us | } 0) + 33.347 us | } 0) 0.651 us | xfs_iunlock(); 0) + 49.613 us | } 0) + 60.186 us | } 0) + 64.090 us | } 0) | xfs_file_release() { 0) | xfs_release() { 0) 0.651 us | xfs_can_free_eofblocks(); 0) | xfs_free_eofblocks() { 0) 0.650 us | xfs_ilock(); 0) | xfs_bmapi_read() { 0) 0.326 us | xfs_isilocked(); 0) | xfs_bmap_search_extents() { 0) | xfs_bmap_search_multi_extents() { 0) | xfs_iext_bno_to_ext() { 0) 0.325 us | xfs_bmbt_get_startoff(); 0) 0.326 us | xfs_bmbt_get_blockcount(); 0) 7.645 us | } 0) 0.325 us | xfs_iext_get_ext(); 0) | xfs_bmbt_get_all() { 0) 0.325 us | __xfs_bmbt_get_all(); 0) 4.067 us | } 0) + 21.960 us | } 0) + 25.376 us | } 0) + 32.696 us | } 0) 0.650 us | xfs_iunlock(); 0) + 44.245 us | } 0) + 54.005 us | } 0) + 57.747 us | } 0) | xfs_file_release() { 0) | xfs_release() { 0) 0.488 us | xfs_can_free_eofblocks(); 0) | xfs_free_eofblocks() { 0) 0.813 us | xfs_ilock(); 0) | xfs_bmapi_read() { 0) 0.325 us | xfs_isilocked(); 0) | xfs_bmap_search_extents() { 0) | xfs_bmap_search_multi_extents() { 0) | xfs_iext_bno_to_ext() { 0) 0.326 us | xfs_bmbt_get_startoff(); 0) 0.325 us | xfs_bmbt_get_blockcount(); 0) 7.645 us | } 0) 0.488 us | xfs_iext_get_ext(); 0) | xfs_bmbt_get_all() { 0) 0.326 us | __xfs_bmbt_get_all(); 0) 4.229 us | } 0) + 22.285 us | } 0) + 25.701 us | } 0) + 32.696 us | } 0) 0.651 us | xfs_iunlock(); 0) + 44.733 us | } 0) + 54.330 us | } 0) + 57.909 us | } 0) | xfs_file_release() { 0) | xfs_release() { 0) 0.651 us | xfs_can_free_eofblocks(); 0) | xfs_free_eofblocks() { 0) 0.650 us | xfs_ilock(); 0) | xfs_bmapi_read() { 0) 0.162 us | xfs_isilocked(); 0) | xfs_bmap_search_extents() { 0) | xfs_bmap_search_multi_extents() { 0) | xfs_iext_bno_to_ext() { 0) 0.325 us | xfs_bmbt_get_startoff(); 0) 0.325 us | xfs_bmbt_get_blockcount(); 0) 9.110 us | } 0) 0.326 us | xfs_iext_get_ext(); 0) | xfs_bmbt_get_all() { 0) 0.325 us | __xfs_bmbt_get_all(); 0) 4.067 us | } 0) + 23.750 us | } 0) + 27.328 us | } 0) + 34.648 us | } 0) 0.651 us | xfs_iunlock(); 0) + 46.522 us | } 0) + 56.283 us | } 0) + 59.861 us | } 0) | xfs_file_release() { 0) | xfs_release() { 0) 0.488 us | xfs_can_free_eofblocks(); 0) | xfs_free_eofblocks() { 0) 0.814 us | xfs_ilock(); 0) | xfs_bmapi_read() { 0) 0.325 us | xfs_isilocked(); 0) | xfs_bmap_search_extents() { 0) | xfs_bmap_search_multi_extents() { 0) | xfs_iext_bno_to_ext() { 0) 0.326 us | xfs_bmbt_get_startoff(); 0) 0.488 us | xfs_bmbt_get_blockcount(); 0) 7.808 us | } 0) 0.325 us | xfs_iext_get_ext(); 0) | xfs_bmbt_get_all() { 0) 0.488 us | __xfs_bmbt_get_all(); 0) 3.904 us | } 0) + 21.960 us | } 0) + 25.376 us | } 0) + 32.696 us | } 0) 0.651 us | xfs_iunlock(); 0) + 44.896 us | } 0) + 54.656 us | } 0) + 58.072 us | } 0) | xfs_file_release() { 0) | xfs_release() { 0) 0.488 us | xfs_can_free_eofblocks(); 0) | xfs_free_eofblocks() { 0) 0.651 us | xfs_ilock(); 0) | xfs_bmapi_read() { 0) 0.325 us | xfs_isilocked(); 0) | xfs_bmap_search_extents() { 0) | xfs_bmap_search_multi_extents() { 0) | xfs_iext_bno_to_ext() { 0) 0.163 us | xfs_bmbt_get_startoff(); 0) 0.325 us | xfs_bmbt_get_blockcount(); 0) 7.808 us | } 0) 0.325 us | xfs_iext_get_ext(); 0) | xfs_bmbt_get_all() { 0) 0.325 us | __xfs_bmbt_get_all(); 0) 3.742 us | } 0) + 21.960 us | } 0) + 25.539 us | } 0) + 32.696 us | } 0) 0.651 us | xfs_iunlock(); 0) + 44.733 us | } 0) + 54.493 us | } 0) + 57.909 us | } 0) 0.814 us | xfs_file_open(); 0) 0.976 us | xfs_vn_getattr(); 0) 1.139 us | xfs_file_mmap(); 0) | xfs_vn_follow_link() { 0) | xfs_readlink() { 0) 0.651 us | xfs_ilock(); 0) 0.650 us | xfs_iunlock(); 0) 9.435 us | } 0) + 14.477 us | } 0) 0.651 us | xfs_file_open(); 0) | xfs_file_read_iter() { 0) 0.814 us | xfs_ilock(); 0) 0.813 us | xfs_iunlock(); 0) + 17.731 us | } 0) 1.138 us | xfs_file_llseek(); 0) | xfs_file_read_iter() { 0) 0.650 us | xfs_ilock(); 0) 0.814 us | xfs_iunlock(); 0) + 18.707 us | } 0) 0.488 us | xfs_file_llseek(); 0) | xfs_file_read_iter() { 0) 0.651 us | xfs_ilock(); 0) 0.650 us | xfs_iunlock(); 0) + 12.200 us | } 0) 0.651 us | xfs_vn_getattr(); 0) 0.651 us | xfs_file_mmap(); 0) 0.976 us | xfs_file_mmap(); 0) | xfs_filemap_fault() { 0) 0.813 us | xfs_ilock(); 0) 0.650 us | xfs_iunlock(); 0) + 10.736 us | } 0) | xfs_file_release() { 0) | xfs_release() { 0) 0.488 us | xfs_can_free_eofblocks(); 0) | xfs_free_eofblocks() { 0) 0.813 us | xfs_ilock(); 0) | xfs_bmapi_read() { 0) 0.326 us | xfs_isilocked(); 0) | xfs_bmap_search_extents() { 0) | xfs_bmap_search_multi_extents() { 0) | xfs_iext_bno_to_ext() { 0) 0.326 us | xfs_bmbt_get_startoff(); 0) 0.325 us | xfs_bmbt_get_blockcount(); 0) 8.133 us | } 0) 0.325 us | xfs_iext_get_ext(); 0) | xfs_bmbt_get_all() { 0) 0.326 us | __xfs_bmbt_get_all(); 0) 3.904 us | } 0) + 22.285 us | } 0) + 25.864 us | } 0) + 33.672 us | } 0) 0.650 us | xfs_iunlock(); 0) + 46.523 us | } 0) + 57.421 us | } 0) + 61.488 us | } 0) 1.138 us | xfs_vn_getattr(); 0) | xfs_vn_unlink() { 0) | xfs_remove() { 0) | xfs_trans_alloc() { 0) 1.464 us | _xfs_trans_alloc(); 0) 6.669 us | } 0) | xfs_trans_reserve() { 0) 1.464 us | xfs_mod_fdblocks(); 0) | xfs_log_reserve() { 0) 0.650 us | xfs_log_calc_unit_res(); 0) + 13.501 us | } 0) + 23.262 us | } 0) 0.976 us | xfs_ilock(); 0) | xfs_lock_two_inodes() { 0) 0.651 us | xfs_ilock(); 0) 0.976 us | xfs_ilock_nowait(); 0) 9.110 us | } 0) 0.326 us | xfs_isilocked(); 0) 1.464 us | xfs_trans_add_item(); 0) 0.488 us | xfs_isilocked(); 0) 1.301 us | xfs_trans_add_item(); 0) 0.488 us | xfs_isilocked(); 0) 0.163 us | xfs_isilocked(); 0) | xfs_droplink() { 0) 0.325 us | xfs_isilocked(); 0) 0.326 us | xfs_isilocked(); 0) | xfs_iunlink() { 0) | xfs_read_agi() { 0) | xfs_buf_read_map() { 0) | xfs_buf_get_map() { 0) | _xfs_buf_find() { 0) 1.301 us | xfs_perag_get(); 0) 0.651 us | xfs_perag_put(); 0) 1.302 us | xfs_buf_trylock(); 0) + 16.754 us | } 0) + 20.984 us | } 0) + 25.051 us | } 0) 1.301 us | xfs_trans_add_item(); 0) + 34.974 us | } 0) + 40.992 us | } 0) + 54.656 us | } 0) | xfs_dir_removename() { 0) | xfs_default_hashname() { 0) 0.325 us | xfs_da_hashname(); 0) 4.392 us | } 0) | xfs_dir2_sf_removename() { 0) 0.651 us | xfs_da_compname(); 0) | xfs_dir2_sfe_get_ino() { 0) 0.326 us | xfs_dir2_sf_get_ino.isra.8(); 0) 4.066 us | } 0) 0.488 us | xfs_dir2_sf_entsize(); 0) 0.651 us | xfs_idata_realloc(); 0) | xfs_dir2_sf_check.isra.6() { 0) | xfs_dir2_sf_get_parent_ino() { 0) 0.325 us | xfs_dir2_sf_get_ino.isra.8(); 0) 3.904 us | } 0) 7.971 us | } 0) 0.326 us | xfs_isilocked(); 0) + 36.600 us | } 0) + 53.030 us | } 0) 0.488 us | xfs_bmap_finish(); 0) | xfs_trans_commit() { 0) 0.326 us | xfs_isilocked(); 0) | xfs_iextents_copy() { 0) 0.488 us | xfs_isilocked(); 0) 0.488 us | xfs_bmap_trace_exlist(); 0) 0.325 us | xfs_iext_get_ext(); 0) 0.488 us | xfs_bmbt_get_startblock(); 0) | xfs_validate_extents() { 0) 0.326 us | xfs_iext_get_ext(); 0) | xfs_bmbt_get_all() { 0) 0.325 us | __xfs_bmbt_get_all(); 0) 3.904 us | } 0) + 11.224 us | } 0) + 30.744 us | } 0) 0.163 us | xfs_isilocked(); 0) 0.488 us | xfs_next_bit(); 0) 0.326 us | xfs_next_bit(); 0) 0.325 us | xfs_next_bit(); 0) 0.325 us | xfs_next_bit(); 0) 0.488 us | xfs_buf_offset(); 0) | xfs_log_done() { 0) 0.488 us | xfs_log_space_wake(); 0) 1.302 us | xfs_log_ticket_put(); 0) + 12.525 us | } 0) | xfs_trans_unreserve_and_mod_sb() { 0) 1.138 us | xfs_mod_fdblocks(); 0) 5.043 us | } 0) | xfs_trans_free_items() { 0) 0.488 us | xfs_isilocked(); 0) 1.302 us | xfs_iunlock(); 0) 1.302 us | xfs_trans_free_item_desc(); 0) 0.488 us | xfs_isilocked(); 0) 0.651 us | xfs_iunlock(); 0) 1.301 us | xfs_trans_free_item_desc(); 0) 1.301 us | xfs_buf_unlock(); 0) 0.814 us | xfs_buf_rele(); 0) 0.976 us | xfs_trans_free_item_desc(); 0) ! 135.176 us | } 0) | xfs_trans_free() { 0) 0.325 us | xfs_extent_busy_clear(); 0) 5.694 us | } 0) ! 247.090 us | } 0) ! 452.702 us | } 0) ! 457.256 us | } 0) 0.488 us | xfs_fs_drop_inode(); 0) | xfs_fs_evict_inode() { [-- Attachment #3: Type: text/plain, Size: 121 bytes --] _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 14+ messages in thread
* xfstests, bad generic tests 009 and 308
@ 2015-09-18 16:16 angelo
0 siblings, 0 replies; 14+ messages in thread
From: angelo @ 2015-09-18 16:16 UTC (permalink / raw)
To: xfs
Hi all,
working on arm (32bit arch), kernel 4.1.6.
Looking to find the reason of a bad result on xfstests,
-tests/generic/009
------------------
i get several "all holes" messages
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.
-tests/generic/308
------------------
I have now: CONFIG_LBDAF=y
In my target device this test creates a 16 Terabytes file 308.tempfile
-rw------- 1 root root 17592186044415 Sep 18 09:40 testfile.308
While "df" is not complaining about:
/dev/mmcblk0p5 8378368 45252 8333116 1% /media/p5
and next rm -f on it hands the cpu to 95%, forever.
This issue seems known from a long time, as it has been discussed in the
thread:
http://oss.sgi.com/archives/xfs/2013-04/msg00273.html
I was wondering if there was any special reason why the Jeff patch has
never been finally applied.
I applied this patch anyway, and tests pass.
Best regards,
Angelo Dureghello
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 14+ messages in threadend of thread, other threads:[~2015-09-27 0:40 UTC | newest] Thread overview: 14+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2015-09-18 16:38 xfstests, bad generic tests 009 and 308 Angelo Dureghello 2015-09-18 22:44 ` Dave Chinner 2015-09-21 11:13 ` Angelo Dureghello 2015-09-21 11:18 ` Angelo Dureghello 2015-09-21 22:52 ` Dave Chinner 2015-09-22 12:41 ` Angelo Dureghello 2015-09-22 21:27 ` Dave Chinner 2015-09-23 9:15 ` Angelo Dureghello 2015-09-23 22:25 ` Dave Chinner 2015-09-23 10:43 ` Yann Dupont - Veille Techno 2015-09-23 22:04 ` Dave Chinner 2015-09-24 8:20 ` Yann Dupont - Veille Techno 2015-09-27 0:40 ` Angelo Dureghello -- strict thread matches above, loose matches on Subject: below -- 2015-09-18 16:16 angelo
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox