public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: Artem Bityutskiy <dedekind1@gmail.com>
To: hujianyang <hujianyang@huawei.com>
Cc: lijinyue@huawei.com, linux-mtd <linux-mtd@lists.infradead.org>,
	yuchangchun1@huawei.com
Subject: Re: Improve UBIFS nospc_retries
Date: Fri, 07 Nov 2014 13:41:59 +0200	[thread overview]
Message-ID: <1415360519.958.324.camel@sauron.fi.intel.com> (raw)
In-Reply-To: <545C9E75.4050709@huawei.com>

On Fri, 2014-11-07 at 18:27 +0800, hujianyang wrote:
> Hi Artem,
> 
> I'm puzzling with *nospc_retries* in make_reservation() nowadays.
> My colleagues in testing department use a less than 20M flash
> and run lots of processes on it. These processes will read, write,
> delete from flash and the flash is always in a nearly-full state.
> The board only has one core.

If it switches to R/O mode, this means that we did not reserve enough
space for the operation. Probably we need to reserve more LEBs for
deletions.

> So, the *nospc_retries* in make_reservation(), line 341 in journal.c
> will easily reach 2 as we set and turn the filesystem to RO mode.
> 
> I know we can't perform an infinite loop here. Can we improve it?
> Not only just turn current *2* to some larger number but also add
> some useful mechanism to avoid filesystem turning to RO mode.

Did you try to increase it, does it help?

We did not stress-test it for small flash size, because we assumed that
JFFS2 would take care of those.

And yes, there may be issues in the "little space left" handling. We
tested that, but no too extensively. The I/O becomes extremely slow when
there is little space, so we preferred to make sure the FS does not get
too full at all by reserving more space for 'root' (UBIFS feature, which
makes sure that 'root' can always write even if users consumed all the
space).

You could also experiment by reserving more LEBs for deletions, and see
if it helps. Just increase 'UBIFS_MIN_MAIN_LEBS' in ubifs.h and run your
test.

  reply	other threads:[~2014-11-07 11:42 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-07 10:27 Improve UBIFS nospc_retries hujianyang
2014-11-07 11:41 ` Artem Bityutskiy [this message]
2014-11-10  1:32   ` hujianyang

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=1415360519.958.324.camel@sauron.fi.intel.com \
    --to=dedekind1@gmail.com \
    --cc=hujianyang@huawei.com \
    --cc=lijinyue@huawei.com \
    --cc=linux-mtd@lists.infradead.org \
    --cc=yuchangchun1@huawei.com \
    /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