UBIFS does not mount after powerfail

[Manfred Spraul]

Hi Richard,

(2nd mail, forced as non-html)

On 11/15/2017 09:29 PM, Richard Weinberger wrote:
> Manfred,
>
> Am Mittwoch, 15. November 2017, 21:04:14 CET schrieb Manfred Spraul:
>> Hi,
>>
>> On 11/14/2017 07:49 PM, Manfred Spraul wrote:
>>> Hi Richard,
>>>
>>> On 11/13/2017 10:06 PM, Richard Weinberger wrote:
>>>> No, the image that contains the first logical error.
>>>> UBIFS can mount even if there are many problems with the structure.
>>>> Therefore I need you to enable chk_fs.
>>> Done - and I even found a 2nd instance where the image got bad:
>>> https://sourceforge.net/projects/calculix-rpm/files/ubifs/chk_fs/
>> Sorry for the self-reply, I did another test:
>> I applied "ubifs: replay: Detect and kill orphaned xattrs", i.e.
>> https://patchwork.ozlabs.org/patch/780667/.
> I would be astonished if that patch would fix your issues, it is supposed
> to fix a -ENOSPC problem.
After enabling chk_fs, the result was
> UBIFS error (ubi0:0 pid 5104): dbg_check_filesystem: inode 39012 nlink is 1, but calculated nlink is 0
and link count 1 instead of 0 sounded a bit like a leak.

dmesg:
https://sourceforge.net/projects/calculix-rpm/files/ubifs/chk_fs/result-168078.txt/download
image:
https://sourceforge.net/projects/calculix-rpm/files/ubifs/chk_fs/image-168078.bin/download

Thus I decided that it might make sense to try a patch that should 
improve the behavior with leaks.
And it did not take much time.

>   
>> Finding 1: It does not help
>> Finding 2: I get for some images lots of "UBIFS error (ubi0:0 pid
>> 13670): ubifs_replay_journal: Expected ino node, got: 1/2/3"
> 1/2/3?
Sorry, that was too short:

https://sourceforge.net/projects/calculix-rpm/files/ubifs/kill_xattr/result-168168.txt/download

> [ 1281.127396] ubi0: background thread "ubi_bgt0d" started, PID 9653
> [ 1281.132641] UBIFS (ubi0:0): background thread "ubifs_bgt0_0" 
> started, PID 9660
> [ 1281.132813] UBIFS (ubi0:0): recovery needed
> [ 1281.137769] UBIFS error (ubi0:0 pid 9658): ubifs_replay_journal: 
> Expected ino node, got: 2
> [ 1281.138860] UBIFS error (ubi0:0 pid 9658): ubifs_replay_journal: 
> Expected ino node, got: 3
> [ 1281.139898] UBIFS error (ubi0:0 pid 9658): ubifs_replay_journal: 
> Expected ino node, got: 2
> [ 1281.140922] UBIFS error (ubi0:0 pid 9658): ubifs_replay_journal: 
> Expected ino node, got: 3
> [ 1281.142023] UBIFS error (ubi0:0 pid 9658): ubifs_replay_journal: 
> Expected ino node, got: 1
> [...]

Image:
https://sourceforge.net/projects/calculix-rpm/files/ubifs/kill_xattr/image-168168.bin/download  


> Is always "got 0xFF but expected something different"?
> If so, it can be a problem with garbage collect.
>> The last good image is e.g. 164908, the first image with such messages
>> is 164909:
>> https://sourceforge.net/projects/calculix-rpm/files/ubifs/kill_xattr/
>>
>> And, perhaps it helps to understand the issues:
>> The stress test is parallel, i.e. 4 parallel bash scripts that do
>> something like "touch a b c ;rm c; mv a b;".
> Hmm, nothing fancy. No O_TMPFILE, no xattr, no encryption. :-(
> I hope I'll find some time during the weekend to inspect your images.
I have attached the generator:
With xattr, due to ecryptfs with ecryptfs_xattr_metadata.

Regarding the "expected ino node":
Is it possible that it is caused by parallel operation?

There are 8 threads that do parallel operations, on a 2-core (4 thread) 
Core-I3 system.
What prevents that another thread creates a journal entry between 
initial UBIFS_XENT_KEY and the two UBIFS_INO_KEY?

If you need something, just send me a mail

--
     Manfred
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gen.sh
Type: application/x-shellscript
Size: 1237 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-mtd/attachments/20171116/ac66b45f/attachment.bin>