From: Adrian Hunter <adrian.hunter@intel.com>
To: Ricard Wanderlof <ricard.wanderlof@axis.com>
Cc: "linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
Robert Homann <homann@bury.com>,
"dedekind1@gmail.com" <dedekind1@gmail.com>
Subject: Re: Resizing of an existing UBIFS
Date: Mon, 04 Jun 2012 10:58:21 +0300 [thread overview]
Message-ID: <4FCC6A9D.4010208@intel.com> (raw)
In-Reply-To: <Pine.LNX.4.64.1206012135000.20240@lnxricardw.se.axis.com>
On 01/06/12 22:47, Ricard Wanderlof wrote:
>
> On Fri, 1 Jun 2012, Adrian Hunter wrote:
>
>> If you let mkfs.ubifs calculate the journal size it will limit it to 8MiB
>> max.
>
> Thanks, that explains the figures then.
>
>> The journal must be scanned after an unclean unmount (e.g. power loss)
>> so a small journal is better for that. However once the journal is full it
>> must be committed which involves a certain amount of overhead so a bigger
>> journal is better for that, but at some point it makes hardly any difference.
>>
>> You can use the flash read speed to get an idea of how big a journal you can
>> live with. e.g. in the worst case you want to mount in 3 seconds, your read
>> speed is 4MiB/s so you need a journal less than 12MiB (but reading the
>> journal is just one part of mounting so maybe 8MiB is better).
>
> So what you're saying is that basically it's the worst-case mount time that
> together with the read speed sets the maximum journal size?
Generally yes.
> I assume if the
> unmount was clean there is no need to read the journal, or does it need to
> be scanned anyway? What if there was an unclean unmount but no data recently
> written so nothing in the journal, does it still have to be scanned in full?
Mounting after a clean unmount is always quicker because the journal is empty.
>
>> You can use the flash write speed to get an idea of how often a commit
>> happens. e.g. flash write speed is 3MiB/s, journal is 4MiB, a commit begins
>> when the journal is 13/16 full, so there is a commit at most once per
>> second, which sounds OK.
>
> In my case there's not a lot of writes (much less than the flash write speed
> would make possible), so even a small journal would probably be ok. Even if
> there were the odd burst of writes we could live with a temporary surge in
> flash writes.
>
> One question here: when one mounts an empty volume, it seems the ubifs
> creates a journal with some default value (which doesn't seem to be
> identical to the defaults that mkfs.ubifs uses). Is there any way to adjust
> those defaults, either with mount command options or with the sysfs?
>
> What I'm getting at in a more concrete sense, is that if I create an empty 8
> MB UBI volume, then mount it as a ubifs file system (rather than
> mkfs.ubifs'ing an empty directory, setting appropriate parameters on the
> mkfs.ubifs command line, and ubiupdatevol'ing that), can I specify a maximum
> LEB count (and fix the journal size) that would be appropriate also for a
> future larger volume size?
No sorry. UBIFS auto-formatting (aka default file system creation) takes no
parameters. Maximum LEB count is simply set to the actual LEB count.
next prev parent reply other threads:[~2012-06-04 7:58 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-22 6:41 Resizing of an existing UBIFS Robert Homann
2012-05-22 6:53 ` Artem Bityutskiy
2012-05-22 7:21 ` Robert Homann
2012-05-22 8:10 ` Artem Bityutskiy
2012-05-22 9:25 ` Robert Homann
2012-05-22 9:40 ` Ricard Wanderlof
2012-05-22 10:19 ` Artem Bityutskiy
2012-05-22 11:11 ` Robert Homann
2012-05-22 11:24 ` Artem Bityutskiy
2012-05-25 7:00 ` Adrian Hunter
2012-05-25 7:49 ` Robert Homann
2012-05-25 8:00 ` Ricard Wanderlof
2012-05-28 9:09 ` Adrian Hunter
2012-06-01 10:10 ` Ricard Wanderlof
2012-06-01 11:48 ` Adrian Hunter
2012-06-01 19:47 ` Ricard Wanderlof
2012-06-04 7:58 ` Adrian Hunter [this message]
2012-06-04 9:35 ` Ricard Wanderlof
2012-06-04 9:47 ` Artem Bityutskiy
2012-05-25 10:12 ` Norbert van Bolhuis
2012-05-26 14:00 ` Artem Bityutskiy
2012-05-27 20:24 ` Norbert van Bolhuis
2012-05-28 5:46 ` 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=4FCC6A9D.4010208@intel.com \
--to=adrian.hunter@intel.com \
--cc=dedekind1@gmail.com \
--cc=homann@bury.com \
--cc=linux-mtd@lists.infradead.org \
--cc=ricard.wanderlof@axis.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.