From: Adrian Hunter <adrian.hunter@intel.com>
To: "Prins Anton (ST-CO/ENG1.1)" <Anton.Prins@nl.bosch.com>
Cc: "linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
"dedekind1@gmail.com" <dedekind1@gmail.com>
Subject: Re: UBIFS failure & stable page writes
Date: Wed, 12 Jun 2013 10:58:21 +0300 [thread overview]
Message-ID: <51B82A1D.30009@intel.com> (raw)
In-Reply-To: <85D877DD6EE67B4A9FCA9B9C3A4865670C3EA0F38E@SI-MBX14.de.bosch.com>
This shows that the orphan area has recorded the orphaning of inode 0 (non-existent!) and inode 1 (root inode!!!).
A sticking plaster solution is to prevent orphans-processing from deleting the root inode e.g.
diff --git a/fs/ubifs/orphan.c b/fs/ubifs/orphan.c
index ba32da3..9400b5b 100644
--- a/fs/ubifs/orphan.c
+++ b/fs/ubifs/orphan.c
@@ -613,6 +613,11 @@ static int do_kill_orphans(struct ubifs_info *c, struct ubifs_scan_leb *sleb,
n = (le32_to_cpu(orph->ch.len) - UBIFS_ORPH_NODE_SZ) >> 3;
for (i = 0; i < n; i++) {
inum = le64_to_cpu(orph->inos[i]);
+ if (inum < UBIFS_FIRST_INO) {
+ ubifs_err("*not* deleting orphaned inode %lu",
+ (unsigned long)inum);
+ continue;
+ }
dbg_rcvry("deleting orphaned inode %lu",
(unsigned long)inum);
err = ubifs_tnc_remove_ino(c, inum);
On 11/06/13 15:16, Prins Anton (ST-CO/ENG1.1) wrote:
> Hi Artem,
>
> We got logging inside the recovery procedure to print the 'orphan LEB' information.
> I wonder if the LEB9 moves yes/no? So is it safe to use 'dd' with an offset of 9*LEB?
> (Difficulty is we have no file system, so this was the first option...)
>
> You see flood of message's; but I suppose the first part is the information required!
> If not I have to make some solution to go for 'dd'.
>
> Thanks in advance,
>
> Anton
>
>
>
> leb9dump-filtered.log
>
>
> UBIFS: parse sync
> UBIFS: recovery needed
> ubi_leb_read datafs 9
> 00000000: 31 18 10 06 1a c9 4a be 09 ca 5d 00 00 00 00 00 28 00 00 00 0b 00 00 00 60 05 00 00 00 00 00 80 1.....J...].....(.......`.......
> 00000020: ea 88 0c 00 00 00 00 00 31 18 10 06 74 7c 20 ed 00 00 00 00 00 00 00 00 1c 00 00 00 05 00 00 00 ........1...t| .................
> 00000040: bc 0f 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................................
> 00000060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................................
struct ubifs_ch {
__le32 magic; 06101831 06101831
__le32 crc; be4ac91a ed207c74
__le64 sqnum; 5dca09 0
__le32 len; 28 1c
__u8 node_type; b=orph 5=pad
__u8 group_type; 0 0
__u8 padding[2]; 0 0
} __packed;
struct ubifs_orph_node {
struct ubifs_ch ch;
__le64 cmt_no; 60 05 00 00 00 00 00 80
__le64 inos[]; 0c88ea
} __packed;
struct ubifs_pad_node {
struct ubifs_ch ch;
__le32 pad_len; 0fbc
} __packed;
<snip>
> 00001000: 31 18 10 06 33 f1 d9 f4 0c 80 6e 00 00 00 00 00 28 00 00 00 0b 00 00 00 73 05 00 00 00 00 00 80 1...3.....n.....(.......s.......
> 00001020: 9f ea 0e 00 00 00 00 00 31 18 10 06 74 7c 20 ed 00 00 00 00 00 00 00 00 1c 00 00 00 05 00 00 00 ........1...t| .................
> 00001040: bc 0f 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................................
> 00001060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................................
__le32 len; 28
__le64 cmt_no; 73 05 00 00 00 00 00 80
__le64 inos[]; 0eea9f
<snip>
> 00002000: 31 18 10 06 c0 79 a0 c5 35 65 6f 00 00 00 00 00 28 00 00 00 0b 00 00 00 74 05 00 00 00 00 00 80 1....y..5eo.....(.......t.......
> 00002020: 4c 0b 0f 00 00 00 00 00 31 18 10 06 74 7c 20 ed 00 00 00 00 00 00 00 00 1c 00 00 00 05 00 00 00 L.......1...t| .................
> 00002040: bc 0f 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................................
> 00002060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................................
__le32 len; 28
__le64 cmt_no; 74 05 00 00 00 00 00 80
__le64 inos[]; 0f0b4c
<snip>
> 00003000: 31 18 10 06 f8 40 ed 34 89 2f 71 00 00 00 00 00 28 00 00 00 0b 00 00 00 76 05 00 00 00 00 00 80 1....@.4./q.....(.......v.......
> 00003020: 00 00 00 00 00 00 00 00 31 18 10 06 74 7c 20 ed 00 00 00 00 00 00 00 00 1c 00 00 00 05 00 00 00 ........1...t| .................
> 00003040: bc 0f 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................................
> 00003060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................................
__le32 len; 28
__le64 cmt_no; 76 05 00 00 00 00 00 80
__le64 inos[]; 0 <----- !!!!!
<snip>
> 00004000: 31 18 10 06 43 37 1d 7e 00 73 77 00 00 00 00 00 28 00 00 00 0b 00 00 00 7d 05 00 00 00 00 00 80 1...C7.~.sw.....(.......}.......
> 00004020: 01 00 00 00 00 00 00 00 31 18 10 06 74 7c 20 ed 00 00 00 00 00 00 00 00 1c 00 00 00 05 00 00 00 ........1...t| .................
> 00004040: bc 0f 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................................
> 00004060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................................
__le32 len; 28
__le64 cmt_no; 7d 05 00 00 00 00 00 80
__le64 inos[]; 1 <----- !!!!!
<snip>
> 00005000: 31 18 10 06 86 67 56 c0 53 c8 7d 00 00 00 00 00 28 00 00 00 0b 00 00 00 84 05 00 00 00 00 00 80 1....gV.S.}.....(...............
> 00005020: 8a 18 11 00 00 00 00 00 31 18 10 06 74 7c 20 ed 00 00 00 00 00 00 00 00 1c 00 00 00 05 00 00 00 ........1...t| .................
> 00005040: bc 0f 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................................
> 00005060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................................
__le32 len; 28
__le64 cmt_no; 84 05 00 00 00 00 00 80
__le64 inos[]; 11188a
<snip>
> 00006000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................................
<snip>
> UBIFS: recovery completed
> UBIFS: mounted UBI device 1, volume 1, name "datafs"
> UBIFS: file system size: 640475136 bytes (625464 KiB, 610 MiB, 1241 LEBs)
> UBIFS: journal size: 10452992 bytes (10208 KiB, 9 MiB, 21 LEBs)
> UBIFS: media format: w4/r0 (latest is w4/r0)
> UBIFS: default compressor: lzo
> UBIFS: reserved for root: 0 bytes (0 KiB)
> UBIFS error (pid 1): ubifs_iget: failed to read inode 1, error -2
> ubifs_fill_super couldn't read UBIFS_ROOT_INO
>
next prev parent reply other threads:[~2013-06-12 7:53 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <85D877DD6EE67B4A9FCA9B9C3A4865670C3E8CB9B7@SI-MBX14.de.bosch.com>
[not found] ` <4BE1E71893EF1E4F9E9DD99FB4EBF0032C02EA2D44@SI-MBX02.de.bosch.com>
[not found] ` <85D877DD6EE67B4A9FCA9B9C3A4865670C3E8CBA85@SI-MBX14.de.bosch.com>
2013-05-27 12:18 ` UBIFS failure & stable page writes Jan Kara
2013-05-27 13:13 ` Prins Anton (ST-CO/ENG1.1)
2013-05-28 2:57 ` Artem Bityutskiy
2013-05-28 7:07 ` Prins Anton (ST-CO/ENG1.1)
2013-05-28 7:44 ` Artem Bityutskiy
2013-05-28 8:18 ` Prins Anton (ST-CO/ENG1.1)
2013-05-28 9:11 ` Artem Bityutskiy
2013-05-28 11:13 ` Prins Anton (ST-CO/ENG1.1)
2013-05-29 6:49 ` Artem Bityutskiy
2013-05-29 11:06 ` Prins Anton (ST-CO/ENG1.1)
2013-05-31 9:51 ` Prins Anton (ST-CO/ENG1.1)
2013-06-03 6:01 ` Artem Bityutskiy
2013-06-11 12:16 ` Prins Anton (ST-CO/ENG1.1)
2013-06-12 7:58 ` Adrian Hunter [this message]
2013-06-12 8:28 ` Prins Anton (ST-CO/ENG1.1)
2013-06-12 11:40 ` Adrian Hunter
2013-06-12 11:13 ` Prins Anton (ST-CO/ENG1.1)
2013-06-12 12:00 ` Adrian Hunter
2013-06-12 11:57 ` Prins Anton (ST-CO/ENG1.1)
2013-06-12 13:09 ` Adrian Hunter
2013-06-12 13:57 ` Prins Anton (ST-CO/ENG1.1)
2013-06-13 10:54 ` Mats Kärrman
2013-06-13 13:31 ` Prins Anton (ST-CO/ENG1.1)
2013-06-13 13:41 ` Adrian Hunter
2013-06-13 14:02 ` Prins Anton (ST-CO/ENG1.1)
2013-06-15 22:25 ` Mats Kärrman
2013-06-13 19:24 ` Prins Anton (ST-CO/ENG1.1)
2013-06-15 22:45 ` Mats Kärrman
2013-06-17 11:20 ` Prins Anton (ST-CO/ENG1.1)
2013-06-18 6:31 ` Prins Anton (ST-CO/ENG1.1)
2013-06-18 7:01 ` Adrian Hunter
2013-06-18 7:17 ` Prins Anton (ST-CO/ENG1.1)
2013-06-25 8:21 ` Prins Anton (ST-CO/ENG1.1)
2013-06-28 9:05 ` Mats Kärrman
2013-06-28 9:27 ` Prins Anton (ST-CO/ENG1.1)
2013-07-25 13:18 ` Prins Anton (ST-CO/ENG1.1)
2013-06-12 7:12 ` Prins Anton (ST-CO/ENG1.1)
2013-05-28 13:00 ` Prins Anton (ST-CO/ENG1.1)
2013-06-13 7:41 ` Adrian Hunter
2013-05-28 8:15 ` Prins Anton (ST-CO/ENG1.1)
2013-05-28 9:09 ` Artem Bityutskiy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=51B82A1D.30009@intel.com \
--to=adrian.hunter@intel.com \
--cc=Anton.Prins@nl.bosch.com \
--cc=dedekind1@gmail.com \
--cc=linux-mtd@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.