Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upbtrfs-progs v5.4.1+ [TEST/mkfs] 020-basic-checksums-mount fails on ppc32, Big Endian #192
Comments
|
Did a re-test with btrfs-progs v5.2.2 and kernel 5.4-rc3. The situation sure hase improved a lot! Of the 22 test failures originally reported here only 4 remain: Some tests were skipped as I did not build btrfs as a module. For some tests I seem to be missing the correct prerequisites (dmsetup, ffsum?) |
ernsteiswuerfel
changed the title
kdave
added a commit
that referenced
this issue
Oct 23, 2019
kdave
added a commit
that referenced
this issue
Oct 25, 2019
kdave
added a commit
that referenced
this issue
Nov 1, 2019
kdave
added a commit
that referenced
this issue
Nov 18, 2019
|
Re-test with btrfs-progs v5.4 and kernel 5.5-rc1: |
ernsteiswuerfel
changed the title
|
@ernsteiswuerfel this happens when your kernel does not have the DM_THIN_PROVISIONING configured. I have a patch read to be submited this error and skip the test. Hopefully I can submit this week. |
marcosps
added a commit
to marcosps/btrfs-progs
that referenced
this issue
Dec 17, 2019
This test can fail due to the lack of kernel support of dm-thin. dmsetup always returns 1 to signify a problem, so we need to check the output of the command to distinguish the lack of dm-thin support or a different error, from the execution without problem, which does not print anything to the stdout. Issue: kdave#192 Signed-off-by: Marcos Paulo de Souza <mpdesouza@suse.com>
marcosps
added a commit
to marcosps/btrfs-progs
that referenced
this issue
Dec 17, 2019
marcosps
added a commit
to marcosps/btrfs-progs
that referenced
this issue
Dec 17, 2019
|
Patches posted in ML: https://lore.kernel.org/linux-btrfs/ |
marcosps
added a commit
to marcosps/btrfs-progs
that referenced
this issue
Dec 17, 2019
marcosps
added a commit
to marcosps/btrfs-progs
that referenced
this issue
Dec 18, 2019
Ah yes, didn't know that. Thanks, also for the patches! With DM_THIN_PROVISIONING enabled the test passes. |
ernsteiswuerfel
changed the title
|
@ernsteiswuerfel it's odd that 018-multidevice-overflow fails. Can you please check which is the problem by looking at tests/mkfs-tests-results.txt ? You can paste the portion related to 018-multidevice test here. Thanks! |
|
@ernsteiswuerfel about 019 and 020, I sent a patch to the ML to run the tests only on supported csum. I don't know if this is your problem, but it may help :) |
|
@marcosps Re-tested with kernel 5.5.3 and btrfs-progs from git-devel which already incorporates the patch you mentioned. |
|
019 passes now, thanks! 020 still fails. |
|
[TEST/misc] 038-backup-root-corruptionon passes now, but [TEST/misc] 034-metadata-uuid fails. Will update bug title accordingly. |
ernsteiswuerfel
changed the title
|
@ernsteiswuerfel can you please retest 019 and 020 again using the latest devel? Today a new patch was merged that could skip these tests when csum hashes are not enabled. About 018 I need to look at this more closely. What we do is create a btrfs on loop device, and then create a huge file, and btrfs can create a 6E filesize, but I don't know how this does not work for you. I will try to get a PPC machine and test it tomorrow. Also, can you post the output of the test 034 that is currently failing as well? Thanks! |
|
Well, I don't have a ppc32 at hand. In this case, can you please return output of the following commads: uname -m I suspect that a 32bit system can only address a couple TB filesizes, and in this case we should skip this test. Thanks for your help! |
Already did that in the posting above, code section. git-devel btrfs-progs tested by me was also latest (73b4b17). |
What a pity I sold a PowerBook G4 of mine some time ago and can't make you an offer now. ;)
Hmm, don't know that. If so, x86, arm, sparc32 and other 32bit arches around should fail this test as well I guess? And thank 'yer all for your work on btrfs! I really do like it's compression features, especially on slower machines with limited disk space. |
marcosps
added a commit
to marcosps/btrfs-progs
that referenced
this issue
Feb 15, 2020
Well, I sent a patch to skip this test in 32bit machines, or at least receive suggestion of how to avoid such situation.
Thanks :D |
marcosps
added a commit
to marcosps/btrfs-progs
that referenced
this issue
Feb 28, 2020
|
@ernsteiswuerfel can you please test btrfs-progs from the following branch? https://github.com/marcosps/btrfs-progs/commits/mpdesouza_tests_ok This branch has fixes that should be merged soon into btrfs-progs, and they are intended to fix your issues like 018 and 034. 020 seems to be fixed as well. Thanks for you help in testing these fixes! |
|
I tested your branch on kernel 5.6-rc3 and 034 is fixed, thanks! However 018 and 020 still fail: All other tests pass. |
ernsteiswuerfel
changed the title
|
@ernsteiswuerfel that's odd. Can you add the results of both tests like you did in #192 (comment)? That would help to understand what's going on. Two other suggestions:
Thanks for you help! |
|
018-multidevice-overflow 020-basic-checksums-mount Deleting tests/test.img and tests/mnt/img* had no effect on the tests. |
marcosps
added a commit
to marcosps/btrfs-progs
that referenced
this issue
Feb 29, 2020
|
@ernsteiswuerfel I guess I found the issue with truncate: it always returns 1. So I needed to compare the output of the command to skip the test or return an error. A new version was pushed to the same branch (if you wanna try... :D ) Now I'm checking the 020, as this seems more tricky... Let me try to reproduce locally or using a PPC64 that I can access... |
Ok, now it skips the test. |
ernsteiswuerfel
changed the title
|
@ernsteiswuerfel great! Just one more issue to tackle. I hope these patches can be merged into devel/master soon. As a matter os test, can you disable xxhash64 and check if the other csum algos work? Thanks a lot! It would make easier to us to test (and to find a proper machine to test on...) |
kdave
added a commit
that referenced
this issue
Mar 2, 2020
kdave
added a commit
that referenced
this issue
Mar 3, 2020
As seem in issue #192, this test can fail from time to time. The issue happens when a mount is issued before the new device is processed by systemd-udevd, as we can see by the og bellow: [ 2346.028809] BTRFS: device fsid 593e23af-a7e6-4360-b16a-229f415de697 devid 1 transid 6 /dev/loop10 scanned by systemd-udevd (3418) [ 2346.265401] BTRFS info (device loop10): found metadata UUID change in progress flag, clearing [ 2346.272474] BTRFS info (device loop10): disk space caching is enabled [ 2346.277472] BTRFS info (device loop10): has skinny extents [ 2346.281840] BTRFS info (device loop10): flagging fs with big metadata feature [ 2346.308428] BTRFS error (device loop10): devid 2 uuid cde07de6-db7e-4b34-909e-d3db6e7c0b06 is missing [ 2346.315363] BTRFS error (device loop10): failed to read the system array: -2 [ 2346.329887] BTRFS error (device loop10): open_ctree failed failed: mount /dev/loop10 /home/marcos/git/suse/btrfs-progs/tests//mnt test failed for case 034-metadata-uuid make: *** [Makefile:401: test-misc] Error 1 [ 2346.666865] BTRFS: device fsid 593e23af-a7e6-4360-b16a-229f415de697 devid 2 transid 5 /dev/loop11 scanned by systemd-udevd (3422) [ 2346.853233] BTRFS: device fsid 1c2debeb-e829-4d6b-84df-aa7c5d246fd5 devid 1 transid 7 /dev/loop6 scanned by systemd-udevd (3418) A few moments after the test failed systemd-udevd processed the new device (registered the new device under btrfs). This can be tested by executing a mount after the test failed, resulting in a successful mount: $ mount /dev/loop10 /mnt [ 2398.955254] BTRFS info (device loop10): found metadata UUID change in progress flag, clearing [ 2398.959416] BTRFS info (device loop10): disk space caching is enabled [ 2398.962483] BTRFS info (device loop10): has skinny extents [ 2398.965070] BTRFS info (device loop10): flagging fs with big metadata feature [ 2399.012617] BTRFS info (device loop10): enabling ssd optimizations [ 2399.022375] BTRFS info (device loop10): checking UUID tree This problem can be avoided is we execute "udevadm settle" before the mount is executed. Issue: #192 Reviewed-by: Nikolay Borisov <nborisov@suse.com> Reviewed-by: Su Yue <Damenly_Su@gmx.com> Signed-off-by: Marcos Paulo de Souza <mpdesouza@suse.com> Signed-off-by: David Sterba <dsterba@suse.com>
kdave
added a commit
that referenced
this issue
Mar 3, 2020
kdave
added a commit
that referenced
this issue
Mar 3, 2020
As seem in issue #192, this test can fail from time to time. The issue happens when a mount is issued before the new device is processed by systemd-udevd, as we can see by the og bellow: [ 2346.028809] BTRFS: device fsid 593e23af-a7e6-4360-b16a-229f415de697 devid 1 transid 6 /dev/loop10 scanned by systemd-udevd (3418) [ 2346.265401] BTRFS info (device loop10): found metadata UUID change in progress flag, clearing [ 2346.272474] BTRFS info (device loop10): disk space caching is enabled [ 2346.277472] BTRFS info (device loop10): has skinny extents [ 2346.281840] BTRFS info (device loop10): flagging fs with big metadata feature [ 2346.308428] BTRFS error (device loop10): devid 2 uuid cde07de6-db7e-4b34-909e-d3db6e7c0b06 is missing [ 2346.315363] BTRFS error (device loop10): failed to read the system array: -2 [ 2346.329887] BTRFS error (device loop10): open_ctree failed failed: mount /dev/loop10 /home/marcos/git/suse/btrfs-progs/tests//mnt test failed for case 034-metadata-uuid make: *** [Makefile:401: test-misc] Error 1 [ 2346.666865] BTRFS: device fsid 593e23af-a7e6-4360-b16a-229f415de697 devid 2 transid 5 /dev/loop11 scanned by systemd-udevd (3422) [ 2346.853233] BTRFS: device fsid 1c2debeb-e829-4d6b-84df-aa7c5d246fd5 devid 1 transid 7 /dev/loop6 scanned by systemd-udevd (3418) A few moments after the test failed systemd-udevd processed the new device (registered the new device under btrfs). This can be tested by executing a mount after the test failed, resulting in a successful mount: $ mount /dev/loop10 /mnt [ 2398.955254] BTRFS info (device loop10): found metadata UUID change in progress flag, clearing [ 2398.959416] BTRFS info (device loop10): disk space caching is enabled [ 2398.962483] BTRFS info (device loop10): has skinny extents [ 2398.965070] BTRFS info (device loop10): flagging fs with big metadata feature [ 2399.012617] BTRFS info (device loop10): enabling ssd optimizations [ 2399.022375] BTRFS info (device loop10): checking UUID tree This problem can be avoided is we execute "udevadm settle" before the mount is executed. Issue: #192 Reviewed-by: Nikolay Borisov <nborisov@suse.com> Reviewed-by: Su Yue <Damenly_Su@gmx.com> Signed-off-by: Marcos Paulo de Souza <mpdesouza@suse.com> Signed-off-by: David Sterba <dsterba@suse.com>
kdave
added a commit
that referenced
this issue
Mar 3, 2020
kdave
added a commit
that referenced
this issue
Mar 4, 2020
As seem in issue #192, this test can fail from time to time. The issue happens when a mount is issued before the new device is processed by systemd-udevd, as we can see by the og bellow: [ 2346.028809] BTRFS: device fsid 593e23af-a7e6-4360-b16a-229f415de697 devid 1 transid 6 /dev/loop10 scanned by systemd-udevd (3418) [ 2346.265401] BTRFS info (device loop10): found metadata UUID change in progress flag, clearing [ 2346.272474] BTRFS info (device loop10): disk space caching is enabled [ 2346.277472] BTRFS info (device loop10): has skinny extents [ 2346.281840] BTRFS info (device loop10): flagging fs with big metadata feature [ 2346.308428] BTRFS error (device loop10): devid 2 uuid cde07de6-db7e-4b34-909e-d3db6e7c0b06 is missing [ 2346.315363] BTRFS error (device loop10): failed to read the system array: -2 [ 2346.329887] BTRFS error (device loop10): open_ctree failed failed: mount /dev/loop10 /home/marcos/git/suse/btrfs-progs/tests//mnt test failed for case 034-metadata-uuid make: *** [Makefile:401: test-misc] Error 1 [ 2346.666865] BTRFS: device fsid 593e23af-a7e6-4360-b16a-229f415de697 devid 2 transid 5 /dev/loop11 scanned by systemd-udevd (3422) [ 2346.853233] BTRFS: device fsid 1c2debeb-e829-4d6b-84df-aa7c5d246fd5 devid 1 transid 7 /dev/loop6 scanned by systemd-udevd (3418) A few moments after the test failed systemd-udevd processed the new device (registered the new device under btrfs). This can be tested by executing a mount after the test failed, resulting in a successful mount: $ mount /dev/loop10 /mnt [ 2398.955254] BTRFS info (device loop10): found metadata UUID change in progress flag, clearing [ 2398.959416] BTRFS info (device loop10): disk space caching is enabled [ 2398.962483] BTRFS info (device loop10): has skinny extents [ 2398.965070] BTRFS info (device loop10): flagging fs with big metadata feature [ 2399.012617] BTRFS info (device loop10): enabling ssd optimizations [ 2399.022375] BTRFS info (device loop10): checking UUID tree This problem can be avoided is we execute "udevadm settle" before the mount is executed. Issue: #192 Reviewed-by: Nikolay Borisov <nborisov@suse.com> Reviewed-by: Su Yue <Damenly_Su@gmx.com> Signed-off-by: Marcos Paulo de Souza <mpdesouza@suse.com> Signed-off-by: David Sterba <dsterba@suse.com>
kdave
added a commit
that referenced
this issue
Mar 4, 2020
kdave
added a commit
that referenced
this issue
Mar 4, 2020
|
I've merged Marcos' patches to devel. There were several problems reported in this issue so I'm not sure if all have been fixed. |
|
@kdave truncate needs to be reworked, as you asked, and there is still the problem with xxhash running on PPC32, that still needs to be found... |
kdave
added a commit
that referenced
this issue
Mar 5, 2020
kdave
added a commit
that referenced
this issue
Mar 6, 2020
|
@marcosps Probably the test itself is ok, but xxhash has a flaw on ppc/ppc64. |
|
@ernsteiswuerfel can you confirm the patch provided by David solves the issue? Thanks! |
|
Yes! Just re-tested with latest git-devel. As this was the last testsuite error left on my ppc32 machine I hereby declare this bug as closed. Millions of G3, G4 and not to forget 604 users will be happy. ;) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Did run the btrfs-progs v5.2.0 tests on my PowerMac G4 DP, these were the failing ones:
One time during testing the kernel had a btrfs hickup (klick) but I was not able to reproduce yet.