All of lore.kernel.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 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.