From: Artem Bityutskiy <dedekind1@gmail.com>
To: Richard Weinberger <richard.weinberger@gmail.com>,
Ryan Meulenkamp <Ryan.Meulenkamp@nedap.com>
Cc: "linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>
Subject: Re: Shrink UBIFS
Date: Mon, 02 Oct 2017 11:27:13 +0300 [thread overview]
Message-ID: <1506932833.14367.529.camel@gmail.com> (raw)
In-Reply-To: <CAFLxGvwoUoH6WDQsexM+H_gdfy3Wd75Oy2BdL8xbdC9TViPazA@mail.gmail.com>
On Sat, 2017-09-30 at 20:09 +0200, Richard Weinberger wrote:
> Ryan,
>
> On Thu, Sep 28, 2017 at 1:43 PM, Ryan Meulenkamp
> <Ryan.Meulenkamp@nedap.com> wrote:
> > Hi,
> >
> >
> > I'm planning to write an ioctl for shrinking a UBIFS to be able to
> > resize the volume its on and create another
> >
> > volume because it is essential for our upgrade/migration flow. Do
> > you guys have any advice for me? The
> >
> > hard part is that LEB's that would fall outside the new size should
> > be moved inside the new size. From what
> >
> > I read, the garbage collection code could be used to accomplish
> > this, but it is not really possible to define
> >
> > which LEB's to put where.
> >
> >
> > Thanks in advance!
>
> So, you want to implement _online_ shrinking?
> This is a way more complicated, think of power-cuts.
> I strongly suggest thinking about offline shrinking first.
>
> You are right, the garbage collector might be useful, you could
> modify
> it in a way
> to move blocks away from to-be-removed LEBs.
> But again, do you *really* need online shrinking?
Yeah, offline would be way easier
But still just thinking aloud about online shrinking...
Suppose we have UBIFS which looks like this.
FDDDEFDFDFFFFFDDDFDFFEEEDFDDDFDFDFDFDFDDDDDDFFFFFFDDDDDDDDDDDFFDFF
F - full eraseblock
D - eraseblock with dirty space.
E - empty eraseblock.
To shrink, we need to turn it into something like this.
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFDDDDEEEEEEEEEEEEEEEEEEEE
Currently GC selects the dirtiest eraseblock as the victim for
cleaning, because this is the most efficient strategy. But you could
introduce a special 'shrinking mode', where you'd tell GC to try hard
picking the victims from the end, Probably also try hard not to re-use
the empty eraseblocks at the end.
Then while being in this mode, GC is used from a background thread to
make enough empty eraseblocks at the end. Well, it is possible that GC
will stop making progress before enough eraseblocks at the end are made
empty, which would mean that further shrinking is impossible.
Just thoughts.
next prev parent reply other threads:[~2017-10-02 8:27 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-28 11:43 Shrink UBIFS Ryan Meulenkamp
2017-09-30 18:09 ` Richard Weinberger
2017-10-02 8:27 ` Artem Bityutskiy [this message]
[not found] ` <1507119835666.14660@nedap.com>
2017-10-04 12:28 ` Richard Weinberger
[not found] ` <1508397182265.19514@nedap.com>
2017-11-06 21:27 ` Richard Weinberger
2017-11-07 7:06 ` 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=1506932833.14367.529.camel@gmail.com \
--to=dedekind1@gmail.com \
--cc=Ryan.Meulenkamp@nedap.com \
--cc=linux-mtd@lists.infradead.org \
--cc=richard.weinberger@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).