public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: Artem Bityutskiy <dedekind1@gmail.com>
To: "Prins Anton (ST-CO/ENG1.1)" <Anton.Prins@nl.bosch.com>
Cc: "linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
	Jan Kara <jack@suse.cz>, Adrian Hunter <adrian.hunter@intel.com>
Subject: Re: UBIFS failure & stable page writes
Date: Mon, 03 Jun 2013 09:01:22 +0300	[thread overview]
Message-ID: <1370239282.21714.21.camel@sauron.fi.intel.com> (raw)
In-Reply-To: <85D877DD6EE67B4A9FCA9B9C3A4865670C3E91E697@SI-MBX14.de.bosch.com>

On Fri, 2013-05-31 at 11:51 +0200, Prins Anton (ST-CO/ENG1.1) wrote:
> Hi Artem,
> 
> Some questions regarding this issue:
> - The orphan area is fixed size, in the implementation we unlink/delete a file 4 times a second... could there be any relation?
>   (How can we calculate the required orphan area size in LEBs?)

No, we stress-tested it with a lot more frequent deletions. I cannot
answer about size calculation off the top of my head, I'd need to read
the code and try calculating. But I guess it is easier to find this out
by writing a small test program which will create create/open/unlink
files until it fails. And you can experiment with amount of orphan LEBs
ans find all the numbers. You can also share them with us :-)

> - Initial the three file systems are programmed if 'flat-image' (ubinized and free space fix-up) from U-boot; can there be an issue?

There were several free space fix-up bug-fixes recently.

I wonder if you have these patches:

0c6c7fa1313fcb69cae35e34168d2e83b8da854a
fe96efc1a3c049f0a1bcd9b65e0faeb751ce5ec6

They prevent from unpleasant bugs in flashers - when you flash a new
image to a flash which alsready contains some UBI stuff, and flasher
does not erase some eraseblocks, the old contents may be treated as part
of the new image, causing really random and subtle problems.

>   (Every ubi-filesystem has its own MTD, so I guess partition separation is guaranteed by the MTD-layer).

Should be.

> - How can I find the orphan LEB(s), to send you some 'contents'?

The LEB numbers range is:

[c->orph_first, c->orph_last]

So all LEBs from c->orph_first to c->orph_last are orphan LEBs.

You can inject printk and print the numbers.

Then you can read the corresponding LEBs directly from /dev/ubiX_Y using
dd. You'll just need to calculate offsets. Offset is LEB number * LEB
size.

-- 
Best Regards,
Artem Bityutskiy

  reply	other threads:[~2013-06-03  5:58 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 [this message]
2013-06-11 12:16                           ` Prins Anton (ST-CO/ENG1.1)
2013-06-12  7:58                             ` Adrian Hunter
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=1370239282.21714.21.camel@sauron.fi.intel.com \
    --to=dedekind1@gmail.com \
    --cc=Anton.Prins@nl.bosch.com \
    --cc=adrian.hunter@intel.com \
    --cc=jack@suse.cz \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox