Resizing of an existing UBIFS

Resizing of an existing UBIFS

[Robert Homann]

Hi,

I have a short question: Is it possible to expand the size of a UBIFS
without creating a new image file or reformatting from scratch?

Suppose you have a UBIFS whose --max-leb-cnt has been set so to limit
its size to 100 MiB. Now suppose this UBIFS lives in a dynamic UBI
volume which gets expanded to a size of the whole partition, say,
150 MiB. Being limited by the --max-leb-cnt parameter, the contained
UBIFS is expanded to only 100 MiB, and the rest of the space in the
volume is wasted. Is it possible to resize the UBIFS so that it can make
use of the now wasted space?

Best regards,
Robert Homann

Re: Resizing of an existing UBIFS

[Artem Bityutskiy]

[-- Attachment #1: Type: text/plain, Size: 798 bytes --]

On Tue, 2012-05-22 at 08:41 +0200, Robert Homann wrote:
> Hi,
> 
> I have a short question: Is it possible to expand the size of a UBIFS
> without creating a new image file or reformatting from scratch?
> 
> Suppose you have a UBIFS whose --max-leb-cnt has been set so to limit
> its size to 100 MiB. Now suppose this UBIFS lives in a dynamic UBI
> volume which gets expanded to a size of the whole partition, say,
> 150 MiB. Being limited by the --max-leb-cnt parameter, the contained
> UBIFS is expanded to only 100 MiB, and the rest of the space in the
> volume is wasted. Is it possible to resize the UBIFS so that it can make
> use of the now wasted space?

Unfortunately there are not tools for this :-( You could write one,
though :-)

-- 
Best Regards,
Artem Bityutskiy

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: Resizing of an existing UBIFS

[Robert Homann]

On 05/22/2012 08:53 AM, Artem Bityutskiy wrote:

Hi!

>> I have a short question: Is it possible to expand the size of a UBIFS
>> without creating a new image file or reformatting from scratch?
>> ...
>
> Unfortunately there are not tools for this :-( You could write one,
> though :-)

OK, thanks. Actually, writing such a tool is not completely out of
question in my case... How hard do you think it would be to implement it?
Would such a tool simply change some values in a few structures or would it
have to do something much more complicated? Or could some existing tool from
mtd-utils be extended to do the job?

Best regards,
Robert Homann

Re: Resizing of an existing UBIFS

[Artem Bityutskiy]

[-- Attachment #1: Type: text/plain, Size: 1407 bytes --]

On Tue, 2012-05-22 at 09:21 +0200, Robert Homann wrote:
> OK, thanks. Actually, writing such a tool is not completely out of
> question in my case... How hard do you think it would be to implement it?
> Would such a tool simply change some values in a few structures or would it
> have to do something much more complicated? Or could some existing tool from
> mtd-utils be extended to do the job?

The idea is that we have on-flash area called "lprops area" which stands
for "LEB properties" and this area contains per-LEB information, e.g.,
how much free space this LEB contains. Obviously - the larger is the UBI
volume, the more LEBs it has, the larger is the lprops area. The lprops
area sits at the beginning of the flash.

When you create the file-system you can specify the size of the lprops
area indirectly using the --max-leb-cnt option. To re-size beyond that,
you need to extend the area, which means that you need to relocate the
contents of LEBs which follow this are further to the end of the device.
This this will change the position of UBIFS nodes, and will re-quire to
amend the indexing information. This is not a simple task, but doable.

However, it may be easier to copy the contents of the entire file-system
to a local machine, then re-create a new image with those files, and
re-flash the device with the new image...

-- 
Best Regards,
Artem Bityutskiy

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: Resizing of an existing UBIFS

[Robert Homann]

On 05/22/2012 10:10 AM, Artem Bityutskiy wrote:

> amend the indexing information. This is not a simple task, but doable.

Thank you a lot for the quick answers! Looks like I need to learn a lot of
details about UBIFS, should I really decide to make such a tool. I'll think
it through again... :)

Best regards,
Robert Homann

Re: Resizing of an existing UBIFS

[Ricard Wanderlof]

On Tue, 22 May 2012, Robert Homann wrote:

> On 05/22/2012 10:10 AM, Artem Bityutskiy wrote:
>
>> amend the indexing information. This is not a simple task, but doable.
>
> Thank you a lot for the quick answers! Looks like I need to learn a lot 
> of details about UBIFS, should I really decide to make such a tool. I'll 
> think it through again... :)

It would also be nice if such a tool could reduce the size of a UBIFS 
volume (given that there is enough free space to do so). That could be 
useful if the contents of a flash at a given point needed to be compacted 
for make room for an additional volume for instance.

/Ricard
-- 
Ricard Wolf Wanderlöf                           ricardw(at)axis.com
Axis Communications AB, Lund, Sweden            www.axis.com
Phone +46 46 272 2016                           Fax +46 46 13 61 30

Re: Resizing of an existing UBIFS

[Artem Bityutskiy]

[-- Attachment #1: Type: text/plain, Size: 1001 bytes --]

On Tue, 2012-05-22 at 11:40 +0200, Ricard Wanderlof wrote:
> On Tue, 22 May 2012, Robert Homann wrote:
> 
> > On 05/22/2012 10:10 AM, Artem Bityutskiy wrote:
> >
> >> amend the indexing information. This is not a simple task, but doable.
> >
> > Thank you a lot for the quick answers! Looks like I need to learn a lot 
> > of details about UBIFS, should I really decide to make such a tool. I'll 
> > think it through again... :)
> 
> It would also be nice if such a tool could reduce the size of a UBIFS 
> volume (given that there is enough free space to do so). That could be 
> useful if the contents of a flash at a given point needed to be compacted 
> for make room for an additional volume for instance.

Yeah, if someone wrote such a tool, it would make sense to support
shrinking as well, because it is roughly a similar thin - you need to
relocate data from the end, amend the index and probably some other
UBIFS data-structures.

-- 
Best Regards,
Artem Bityutskiy

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: Resizing of an existing UBIFS

[Robert Homann]

On 05/22/2012 12:19 PM, Artem Bityutskiy wrote:

> Yeah, if someone wrote such a tool, it would make sense to support
> shrinking as well, because it is roughly a similar thin - you need to
> relocate data from the end, amend the index and probably some other
> UBIFS data-structures.

This is getting interesting.

On which level would such a tool operate? I guess it would have to do some
low-level operations directly on UBIFS structures, but it would use the UBI
layer below only to get at the corresponding blocks. Other than that, the UBI
structures would not require direct manipulations, am I right? In this case,
such a tool could be implemented without strict dependency on UBI.

Or would it be necessary to also touch UBI structures directly, in which case
I guess it would become much more messy?

Best regards,
Robert Homann

Re: Resizing of an existing UBIFS

[Artem Bityutskiy]

[-- Attachment #1: Type: text/plain, Size: 1242 bytes --]

On Tue, 2012-05-22 at 13:11 +0200, Robert Homann wrote:
> On 05/22/2012 12:19 PM, Artem Bityutskiy wrote:
> 
> > Yeah, if someone wrote such a tool, it would make sense to support
> > shrinking as well, because it is roughly a similar thin - you need to
> > relocate data from the end, amend the index and probably some other
> > UBIFS data-structures.
> 
> This is getting interesting.
> 
> On which level would such a tool operate? I guess it would have to do some
> low-level operations directly on UBIFS structures, but it would use the UBI
> layer below only to get at the corresponding blocks. Other than that, the UBI
> structures would not require direct manipulations, am I right? In this case,
> such a tool could be implemented without strict dependency on UBI.

It would work directly with the UBI volume. It would need to know the
UBIFS data structures. Yes, you should not have strict dependency on
UBI. Well, may be you'd need to use UBI ioctls to write your data back
to the eraseblock.

> Or would it be necessary to also touch UBI structures directly, in which case
> I guess it would become much more messy?

No, you should not need to touch UBI structures.

-- 
Best Regards,
Artem Bityutskiy

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: Resizing of an existing UBIFS

[Adrian Hunter]

On 22/05/12 10:21, Robert Homann wrote:
> On 05/22/2012 08:53 AM, Artem Bityutskiy wrote:
> 
> Hi!
> 
>>> I have a short question: Is it possible to expand the size of a UBIFS
>>> without creating a new image file or reformatting from scratch?
>>> ...
>>
>> Unfortunately there are not tools for this :-( You could write one,
>> though :-)
> 
> OK, thanks. Actually, writing such a tool is not completely out of
> question in my case... How hard do you think it would be to implement it?
> Would such a tool simply change some values in a few structures or would it
> have to do something much more complicated? Or could some existing tool from
> mtd-utils be extended to do the job?

Before writing a tool you should check how much overhead there is in simply
making max-leb-cnt as big as you might ever want.

Re: Resizing of an existing UBIFS

[Robert Homann]

On 05/25/2012 09:00 AM, Adrian Hunter wrote:

Hi!

> Before writing a tool you should check how much overhead there is in simply
> making max-leb-cnt as big as you might ever want.

It is definitely a lot simpler to just set this parameter to some big value
and generate new images from scratch since the overhead in space consumption
is not an issue in this case. But let's say, in my case the purpose of using
such a resizing tool is not space optimization, but fixing a former
decision...

I still need to think about whether or not it is worth the effort to write a
resizing tool. Should I decide to make it, I'll first ask around on this list
to provide some suggestions about the features that could and should be
supported while at it. Don't hold your breath, though. :)

Best regards,
Robert Homann

Re: Resizing of an existing UBIFS

[Ricard Wanderlof]

On Fri, 25 May 2012, Robert Homann wrote:

> It is definitely a lot simpler to just set this parameter to some big 
> value and generate new images from scratch since the overhead in space 
> consumption is not an issue in this case. But let's say, in my case the 
> purpose of using such a resizing tool is not space optimization, but 
> fixing a former decision...

I think this is a most important point. Whatever sizing strategy and 
volume sizes that are decided upon, one can be sure that a couple of years 
down the line differing circumstances will require a re-think of that 
strategy, no matter how well founded the decision was to start with.

/Ricard
-- 
Ricard Wolf Wanderlöf                           ricardw(at)axis.com
Axis Communications AB, Lund, Sweden            www.axis.com
Phone +46 46 272 2016                           Fax +46 46 13 61 30

Re: Resizing of an existing UBIFS

[Norbert van Bolhuis]

On 05/22/12 08:53, Artem Bityutskiy wrote:
> On Tue, 2012-05-22 at 08:41 +0200, Robert Homann wrote:
>> Hi,
>>
>> I have a short question: Is it possible to expand the size of a UBIFS
>> without creating a new image file or reformatting from scratch?
>>
>> Suppose you have a UBIFS whose --max-leb-cnt has been set so to limit
>> its size to 100 MiB. Now suppose this UBIFS lives in a dynamic UBI
>> volume which gets expanded to a size of the whole partition, say,
>> 150 MiB. Being limited by the --max-leb-cnt parameter, the contained
>> UBIFS is expanded to only 100 MiB, and the rest of the space in the
>> volume is wasted. Is it possible to resize the UBIFS so that it can make
>> use of the now wasted space?
>
> Unfortunately there are not tools for this :-( You could write one,
> though :-)
>


This is not a problem for a UBIFS being created dynamically, so with
ubiformat + ubiattach + ubimkvol ? In this case the size of the lprops
area is determined by the total amount of LEBs of the MTD partition ?

A UBIFS volume can then be resized with ubirsvol as long as it does not
conflict with other volumes and does not exceed the total amount of
LEBs of the MTD partition ?

---
N. van Bolhuis.

Re: Resizing of an existing UBIFS

[Artem Bityutskiy]

[-- Attachment #1: Type: text/plain, Size: 782 bytes --]

On Fri, 2012-05-25 at 12:12 +0200, Norbert van Bolhuis wrote:
> This is not a problem for a UBIFS being created dynamically, so with
> ubiformat + ubiattach + ubimkvol ? In this case the size of the lprops
> area is determined by the total amount of LEBs of the MTD partition ?

No, it is set according to the --max-leb-cnt parameter. Then UBIFS will
be able to grow up to "--max-leb-cnt" easily.

> A UBIFS volume can then be resized with ubirsvol as long as it does not
> conflict with other volumes and does not exceed the total amount of
> LEBs of the MTD partition ?

Yes, and if you resize withing '--max-leb-cnt', the UBIFS will
automatically resize itself.

http://linux-mtd.infradead.org/faq/ubifs.html#L_max_leb_cnt

-- 
Best Regards,
Artem Bityutskiy

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: Resizing of an existing UBIFS

[Norbert van Bolhuis]

On 05/26/12 16:00, Artem Bityutskiy wrote:
> On Fri, 2012-05-25 at 12:12 +0200, Norbert van Bolhuis wrote:
>> This is not a problem for a UBIFS being created dynamically, so with
>> ubiformat + ubiattach + ubimkvol ? In this case the size of the lprops
>> area is determined by the total amount of LEBs of the MTD partition ?
>
> No, it is set according to the --max-leb-cnt parameter. Then UBIFS will
> be able to grow up to "--max-leb-cnt" easily.
>
>> A UBIFS volume can then be resized with ubirsvol as long as it does not
>> conflict with other volumes and does not exceed the total amount of
>> LEBs of the MTD partition ?
>
> Yes, and if you resize withing '--max-leb-cnt', the UBIFS will
> automatically resize itself.
>
> http://linux-mtd.infradead.org/faq/ubifs.html#L_max_leb_cnt
>

I was asking because there is no --max-leb-cnt parameter wen creating a UBIFS
dynamically, or is there ?

---
N. van Bolhuis.

Re: Resizing of an existing UBIFS

[Artem Bityutskiy]

[-- Attachment #1: Type: text/plain, Size: 1159 bytes --]

On Sun, 2012-05-27 at 22:24 +0200, Norbert van Bolhuis wrote:
> On 05/26/12 16:00, Artem Bityutskiy wrote:
> > On Fri, 2012-05-25 at 12:12 +0200, Norbert van Bolhuis wrote:
> >> This is not a problem for a UBIFS being created dynamically, so with
> >> ubiformat + ubiattach + ubimkvol ? In this case the size of the lprops
> >> area is determined by the total amount of LEBs of the MTD partition ?
> >
> > No, it is set according to the --max-leb-cnt parameter. Then UBIFS will
> > be able to grow up to "--max-leb-cnt" easily.
> >
> >> A UBIFS volume can then be resized with ubirsvol as long as it does not
> >> conflict with other volumes and does not exceed the total amount of
> >> LEBs of the MTD partition ?
> >
> > Yes, and if you resize withing '--max-leb-cnt', the UBIFS will
> > automatically resize itself.
> >
> > http://linux-mtd.infradead.org/faq/ubifs.html#L_max_leb_cnt
> >
> 
> I was asking because there is no --max-leb-cnt parameter wen creating a UBIFS
> dynamically, or is there ?

Ah, you mean when mounting an empty volume? No there is not, UBIFS just
picks some value.

-- 
Best Regards,
Artem Bityutskiy

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: Resizing of an existing UBIFS

[Adrian Hunter]

On 25/05/12 11:00, Ricard Wanderlof wrote:
> 
> On Fri, 25 May 2012, Robert Homann wrote:
> 
>> It is definitely a lot simpler to just set this parameter to some big
>> value and generate new images from scratch since the overhead in space
>> consumption is not an issue in this case. But let's say, in my case the
>> purpose of using such a resizing tool is not space optimization, but
>> fixing a former decision...
> 
> I think this is a most important point. Whatever sizing strategy and volume
> sizes that are decided upon, one can be sure that a couple of years down the
> line differing circumstances will require a re-think of that strategy, no
> matter how well founded the decision was to start with.

Unless you set max_leb_cnt to match the media size.

The point is resizing when max_leb_cnt is not changed is much simpler.

Re: Resizing of an existing UBIFS

[Ricard Wanderlof]

On Mon, 28 May 2012, Adrian Hunter wrote:

> On 25/05/12 11:00, Ricard Wanderlof wrote:
>>
>> On Fri, 25 May 2012, Robert Homann wrote:
>>
>>> It is definitely a lot simpler to just set this parameter to some big
>>> value and generate new images from scratch since the overhead in space
>>> consumption is not an issue in this case. But let's say, in my case the
>>> purpose of using such a resizing tool is not space optimization, but
>>> fixing a former decision...
>>
>> I think this is a most important point. Whatever sizing strategy and volume
>> sizes that are decided upon, one can be sure that a couple of years down the
>> line differing circumstances will require a re-think of that strategy, no
>> matter how well founded the decision was to start with.
>
> Unless you set max_leb_cnt to match the media size.
>
> The point is resizing when max_leb_cnt is not changed is much simpler.

One point I ran into though is that when specifying a larger max-leb-cnt 
than the size of the volume, by default the journal size also increases
(it is according to Artem 12% of the max-leb-cnt 
(http://lists.infradead.org/pipermail/linux-mtd/2012-March/040084.html), 
but on my system it seems to be less than that and varies with the LEB 
count; see below - perhaps 12% is the maximum size?).

I've got a 128 MB flash with 128 kB blocks on my system, i.e. a LEB size 
of 129024 and a total LEB count for the whole device of 1024.

Say you have an ~8 MB volume on the flash = 65 LEBs, and you create a file 
system image for it with a max-leb-cnt of 65. This results in a default 
journal size of 903168 bytes according to mkfs.ubifs -v. (Incidentally, 
the journal size here appears to be about 11% of the total LEB count for 
the volume.)

If you now create a file system image with a max-leb-cnt of 1024, this 
results in a default journal size of 8388608 = 8M which is larger than the 
space available in the volume. (Incidentally, the journal size in this 
case appears to be about 6% of the total LEB count specified).

Of course, the volume size could be set to, say, 16 MB instead, but 
neverthless, 8 MB of this 16 MB volume is then wasted for a journal 
intended to fit a (future) larger volume size.

So, just increasing max-leb-cnt causes a lot of wasted space in a small 
volume by default. Of course one could specify a smaller journal size, the 
question is then what journal size to set? Are there any guidelines which 
would be helpful in this case (Artem?) ?

/Ricard
-- 
Ricard Wolf Wanderlöf                           ricardw(at)axis.com
Axis Communications AB, Lund, Sweden            www.axis.com
Phone +46 46 272 2016                           Fax +46 46 13 61 30

Re: Resizing of an existing UBIFS

[Adrian Hunter]

On 01/06/12 13:10, Ricard Wanderlof wrote:
> 
> On Mon, 28 May 2012, Adrian Hunter wrote:
> 
>> On 25/05/12 11:00, Ricard Wanderlof wrote:
>>>
>>> On Fri, 25 May 2012, Robert Homann wrote:
>>>
>>>> It is definitely a lot simpler to just set this parameter to some big
>>>> value and generate new images from scratch since the overhead in space
>>>> consumption is not an issue in this case. But let's say, in my case the
>>>> purpose of using such a resizing tool is not space optimization, but
>>>> fixing a former decision...
>>>
>>> I think this is a most important point. Whatever sizing strategy and volume
>>> sizes that are decided upon, one can be sure that a couple of years down the
>>> line differing circumstances will require a re-think of that strategy, no
>>> matter how well founded the decision was to start with.
>>
>> Unless you set max_leb_cnt to match the media size.
>>
>> The point is resizing when max_leb_cnt is not changed is much simpler.
> 
> One point I ran into though is that when specifying a larger max-leb-cnt
> than the size of the volume, by default the journal size also increases
> (it is according to Artem 12% of the max-leb-cnt
> (http://lists.infradead.org/pipermail/linux-mtd/2012-March/040084.html), but
> on my system it seems to be less than that and varies with the LEB count;
> see below - perhaps 12% is the maximum size?).
> 
> I've got a 128 MB flash with 128 kB blocks on my system, i.e. a LEB size of
> 129024 and a total LEB count for the whole device of 1024.
> 
> Say you have an ~8 MB volume on the flash = 65 LEBs, and you create a file
> system image for it with a max-leb-cnt of 65. This results in a default
> journal size of 903168 bytes according to mkfs.ubifs -v. (Incidentally, the
> journal size here appears to be about 11% of the total LEB count for the
> volume.)
> 
> If you now create a file system image with a max-leb-cnt of 1024, this
> results in a default journal size of 8388608 = 8M which is larger than the
> space available in the volume. (Incidentally, the journal size in this case
> appears to be about 6% of the total LEB count specified).

If you let mkfs.ubifs calculate the journal size it will limit it to 8MiB max.

> 
> Of course, the volume size could be set to, say, 16 MB instead, but
> neverthless, 8 MB of this 16 MB volume is then wasted for a journal intended
> to fit a (future) larger volume size.
> 
> So, just increasing max-leb-cnt causes a lot of wasted space in a small
> volume by default. Of course one could specify a smaller journal size, the
> question is then what journal size to set? Are there any guidelines which
> would be helpful in this case (Artem?) ?

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).

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.

> 
> /Ricard

Re: Resizing of an existing UBIFS

[Ricard Wanderlof]

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? 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?

> 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?

/Ricard
-- 
Ricard Wolf Wanderlöf                           ricardw(at)axis.com
Axis Communications AB, Lund, Sweden            www.axis.com
Phone +46 46 272 2016                           Fax +46 46 13 61 30

Re: Resizing of an existing UBIFS

[Adrian Hunter]

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.

Re: Resizing of an existing UBIFS

[Ricard Wanderlof]

On Mon, 4 Jun 2012, Adrian Hunter wrote:

>> 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.

>> 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.

Ok, thanks for confirming that.

I suppose it would be possible to add some sysfs-parameter or similar to 
add this functionality?

/Ricard
-- 
Ricard Wolf Wanderlöf                           ricardw(at)axis.com
Axis Communications AB, Lund, Sweden            www.axis.com
Phone +46 46 272 2016                           Fax +46 46 13 61 30

Re: Resizing of an existing UBIFS

[Artem Bityutskiy]

[-- Attachment #1: Type: text/plain, Size: 487 bytes --]

On Mon, 2012-06-04 at 11:35 +0200, Ricard Wanderlof wrote:
> I suppose it would be possible to add some sysfs-parameter or similar to 
> add this functionality?

I do not think we would want to have it. If we add one parameter today,
there will be much more tomorrow. The autoformat feature was only meant
for developers' convenience. If you can set the flag in user-space, you
can as well run mkfs.ubifs with all the parameters you want.

-- 
Best Regards,
Artem Bityutskiy

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]