From: hujianyang <hujianyang@huawei.com>
To: <dedekind1@gmail.com>
Cc: lijinyue@huawei.com, linux-mtd <linux-mtd@lists.infradead.org>,
yuchangchun1@huawei.com
Subject: Re: Improve UBIFS nospc_retries
Date: Mon, 10 Nov 2014 09:32:30 +0800 [thread overview]
Message-ID: <546015AE.6060808@huawei.com> (raw)
In-Reply-To: <1415360519.958.324.camel@sauron.fi.intel.com>
On 2014/11/7 19:41, Artem Bityutskiy wrote:
> 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?
>
Yes, I've increased it to 5, and see it takes a longer time to
switch to RO. I add some log messages when nospc_retries increase
to 2 and filesystem will work OK when nospc_retries hits 2. But it
will turn to RO when nospc_retries equals to 5.
> 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).
I think you are right. Runing UBIFS on a small flash device will
waste high percents of 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.
>
Thanks. I think it will help~! I will try to increase this.
Hu
>
>
> .
>
prev parent reply other threads:[~2014-11-10 1:37 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
2014-11-10 1:32 ` hujianyang [this message]
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=546015AE.6060808@huawei.com \
--to=hujianyang@huawei.com \
--cc=dedekind1@gmail.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 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.