Closed bugmenot2 closed 7 years ago
Unfortunately debugging mode works incorrectly in reiser4. Why have you enabled it?
Before this I was getting kernel panic on kernel 4.8 ("kernel BUG at fs/reiser4/block_alloc.c: 152" if I remember correctly), so I decided to enable debugging when building 4.10. Ok, I'll try with debugging disabled then.
Is it reproducible? Anyway, debugging mode won't help here.
Yes, I keep getting block_alloc.c:152 assert on 4.8: https://lut.im/8AqQyzPkpd/a6x4szCgIyXrfEPt.JPG https://lut.im/QhPkHytXRm/Z214fmeyedbXOCs1.JPG I can upload FS metadata if it can help.
Interesting. I'll examine that path carefully.. The second stack-trace is a side-effect, as I understand? Metadata is not needed. Thanks!
(sorry, have to use a different account)
The second stack-trace is a side-effect, as I understand?
Yes, it appears later on.
4.8: After I removed ureadahead package, the block_alloc assert is gone...
4.10: I've noticed the following warnings (note that I haven't yet rebuilt the kernel without debugging, might be related to that):
reiser4[baloo_file(2053)]: release_unix_file (fs/reiser4/plugin/file/file.c:2358)[vs-44]
WARNING: out of memory?
reiser4[wicd(1172)]: release_unix_file (fs/reiser4/plugin/file/file.c:2358)[vs-44]
WARNING: out of memory?
4.8: It's a pity that it has gone: I wanted you to reproduce it with some my debugging extension. Someone steals space reservation (one block per file for stat-data update) which is needed for marking the file accessible after read is done.
4.10: Please, rebuild the kernel without debugging option, and let me know, if something goes wrong.
I haven't encountered any problems after disabling debugging, so feel free to close this ticket.
4.8: Most probably that at some point of the read path a memory allocation happens against memory pressure in the system. The triggered writeback fails with ENOSPC, and our reservation gets released in the error path. Then the read path resumes without any reservation - it leads to kernel BUG at fs/reiser4/block_alloc.c: 152. I fixed reiser4-for-4.9.3 (9eca07b), so that writeback doesn't fail now - this is why you don't have such problems in 4.10. But again - all this is just an assumption. Anyway, the code needs more love...
I'm getting this trace when booting from reiser4 partition (debugging enabled in kernel config):
fsck reports that the filesystem is clean. What can this be? Tell me if additional information is needed.