public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: Artem Bityutskiy <dedekind1@gmail.com>
To: Jon Ringle <jon@ringle.org>
Cc: linux-mtd@lists.infradead.org
Subject: Re: shrinking ubifs?
Date: Wed, 27 Jan 2010 18:25:00 +0200	[thread overview]
Message-ID: <1264609500.1973.42.camel@localhost> (raw)
In-Reply-To: <152584231001221121u2ffc1816o18d71e6099f8fc6@mail.gmail.com>

On Fri, 2010-01-22 at 14:21 -0500, Jon Ringle wrote:
> On Sun, Jan 17, 2010 at 5:40 AM, Artem Bityutskiy <dedekind1@gmail.com> wrote:
> > On Thu, 2010-01-14 at 17:15 -0500, Jon Ringle wrote:
> >> On ubi0, I have 3 volumes:
> >> ubi0_0 kernel (static volume)
> >> ubi0_1 squashfs (static volume)
> >> ubi0_2 ubifs (dynamic volume)
> >>
> >> When I create the volumes, the static volumes are created first and
> >> then the ubifs volume is created with whatever LEBs are left over. I
> >> am using the squashfs and ubifs in a aufs2 union fs. When I need to
> >> reflash either of the static volumes for an upgrade, and the new
> >> images don't fit the space available in the LEBs reserved in the
> >> corresponding static volume, I remove the ubifs volume to create space
> >> and then recreate the ubifs volume again with what is remaining. This
> >> is sub-optimal as this means that and data on the ubifs is now lost.
> >
> > Yes, this is not optimal. However, ubifs shrinking is not implemented.
> > One could UBIFS ioctl to shring the FS, though, it should not be
> > extremely difficult. It is about garbage-collecting the last LEBs to
> > somewhere else, and amending the master block.
> >
> >> Is there a way to shrink a UBIFS if there are unused LEBs in the UBIFS?
> >
> > Not at the moment, this would need some development.
> 
> How about the opposite. If the static volumes became smaller freeing
> up some LEBs. Can the UBIFS be expanded to make use of the freed LEBs?

That works automatically. UBIFS expands automatically, but up to the
size which you specified with the '-c' mkfs.ubifs option.

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

-- 
Best Regards,
Artem Bityutskiy (Артём Битюцкий)

  reply	other threads:[~2010-01-27 16:25 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-01-14 22:15 shrinking ubifs? Jon Ringle
2010-01-17 10:40 ` Artem Bityutskiy
2010-01-22 19:21   ` Jon Ringle
2010-01-27 16:25     ` Artem Bityutskiy [this message]
2010-01-27 16:34       ` Jon Ringle
2010-01-27 16:35         ` Artem Bityutskiy
2010-02-01  4:01           ` Jon Ringle
2010-02-01  4:30             ` 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=1264609500.1973.42.camel@localhost \
    --to=dedekind1@gmail.com \
    --cc=jon@ringle.org \
    --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