dagargo / emu3fs

Linux kernel module for the E-Mu EIII and EIV sampler filesystems

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

RPi intermittent test failure

raybellis opened this issue · comments

Running current master branch on RPi with kernel 5.10.63, I've seen this error occur a couple of times in tests, but not every time:

Running 'rmdir mountpoint/foo'...
rmdir: failed to remove 'mountpoint/foo': Directory not empty
Results: 46/47

emu3fs: Test error: Sun Jan 16 13:53:36 GMT 2022
[485778.640651] emu3fs: root start block @ 6 + 3 blocks
[485778.640662] emu3fs: dir content start block @ 9 + 106 blocks
[485778.640672] emu3fs: data start block @ 115 + 967 clusters
[485779.161892] emu3fs: *** Test: mkdir and rmdir ***
[485779.286131] emu3fs: 990976 physical blocks, 990317 addressable blocks, 967 clusters, 1024 blocks/cluster
[485779.286158] emu3fs: cluster list start block @ 2 + 4 blocks
[485779.286170] emu3fs: root start block @ 6 + 3 blocks
[485779.286181] emu3fs: dir content start block @ 9 + 106 blocks
[485779.286191] emu3fs: data start block @ 115 + 967 clusters
[485779.595526] emu3fs: *** Test: File creation and basic edition ***
[485779.886570] emu3fs: *** Test: cp ***
[485780.109252] emu3fs: *** Test: mv ***
[485780.362898] emu3fs: *** Test: cp with big files ***
[485792.728411] emu3fs: 990976 physical blocks, 990317 addressable blocks, 967 clusters, 1024 blocks/cluster
[485792.728439] emu3fs: cluster list start block @ 2 + 4 blocks
[485792.728451] emu3fs: root start block @ 6 + 3 blocks
[485792.728462] emu3fs: dir content start block @ 9 + 106 blocks
[485792.728472] emu3fs: data start block @ 115 + 967 clusters
[485799.722175] emu3fs: *** Test: Truncate ***
[485800.384860] emu3fs: Test error: Sun Jan 16 13:53:36 GMT 2022

Yeah, it's an old issue with the tests I've never focus on. Repeating the tests has always been successful so I think is a problem of the tests themselves.

I'll try to fix it now that someone else is using the tests but I'm not even sure if I'll be able to replicate since I think it was happening just after the tests failed.

It still happens.

I'm using this patch to try to see what the state of the FS is before that rmdir intermittently fails:

diff --git a/tests/tests.sh b/tests/tests.sh
index 1d33b44..9913817 100755
--- a/tests/tests.sh
+++ b/tests/tests.sh
@@ -205,6 +205,7 @@ test
 logAndRun rm $EMU3_MOUNTPOINT/foo/t*
 test foo
 
+ls -lR $EMU3_MOUNTPOINT/foo
 logAndRun rmdir $EMU3_MOUNTPOINT/foo
 test .

Fixed in e672db7.

The problem was caused by using an int to store a short losing the sign, thus 0xffff was not interpreted as an unused block (-1) but as the 2^16 - 1 block.

What made the failure random was the data stored in that block, which was random and was generated a few tests before.

The issue was only affecting rmdir.

Just test this a bit and we'll consider this actually fixed.

well spotted! I can't imagine that was easy to find...

BTW, this affected every architecture.

I suspected it would when you reported you'd also seen it. As luck would have it, I only saw it on my RPi install.

In the end, it wasn't a test issue as I suspected so thank you so much for reporting this and helping to solve it.