From: Richard Weinberger <richard@nod.at>
To: dedekind1@gmail.com
Cc: Heinz.Egger@linutronix.de, tglx@linutronix.de,
linux-mtd@lists.infradead.org, tim.bird@am.sony.com,
linux-kernel@vger.kernel.org
Subject: Re: [RFC v2] UBI: UBIVIS (aka checkpointing) support
Date: Thu, 10 May 2012 10:33:52 +0200 [thread overview]
Message-ID: <4FAB7D70.1040704@nod.at> (raw)
In-Reply-To: <1336624000.1936.22.camel@brekeke>
[-- Attachment #1: Type: text/plain, Size: 2090 bytes --]
Hi Artem!
Am 10.05.2012 06:26, schrieb Artem Bityutskiy:
> Hi Richard, I would like to complain about the names again. I though I
> better give this feed back as soon as possible...
No problem. :)
> Firs of all, thanks for doing this, I will look closer, and I am very
> keen of merging this stuff once we are sure its design is good, allows
> for future extensions and is backward-compatible.
>
Yeah.
First of all, yes it's fully backward-compatible. It uses two new internal volume IDs
with compat = UBI_COMPAT_DELETE.
Old UBI implementations will delete the checkpoint and continue with scanning...
Regarding design, ubi_wl_get_peb() currently offers three types of data types.
UBI_LONGTERM, UBI_SHORTTERM and UBI_UNKNOWN. Do we really need them?
Checkpointing has a pool of unknown PEBs. This PEBs have to be scanned while attaching.
For now I had to create three pools (for UBI_LONGTERM, UBI_SHORTTERM and UBI_UNKNOWN).
This makes the whole thing complexer than needed.
It introduces also some nasty corner cases.
To make the review easier for you:
The most critical code path is scan_pool() -> process_pool_seb() -> update_vol().
It searches within a pool for PEBs which are no longer empty and scans them.
After that it updates the corresponding volume.
ubi_update_checkpoint() is also very important because it has to find
unused PEBs at the beginning of the MTD to place the super block.
> So may be just naming your stuff UBI2, having terms like "UBI2 format",
> would be the easiest? Then someone could make this to be UBI3. A
> documentation section could describe what UBI2 is and how it is
> different from UBI1 or just UBI.
Okay, got your point.
I think "fastmap" is a good name because I can also use it within the code.
So, while reviewing the code please keep s/checkpoint/fastmap/g and s/cp/fm/g in mind. ;-)
I like the UBI2 idea. UBI2 = UBI + fastmap.
After the UBI2/fastmap design is stable I will happily write a detailed design paper
for http://www.linux-mtd.infradead.org/doc/ubi.html.
Thanks,
//richard
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: Richard Weinberger <richard@nod.at>
To: dedekind1@gmail.com
Cc: linux-mtd@lists.infradead.org, tim.bird@am.sony.com,
tglx@linutronix.de, linux-kernel@vger.kernel.org,
Heinz.Egger@linutronix.de
Subject: Re: [RFC v2] UBI: UBIVIS (aka checkpointing) support
Date: Thu, 10 May 2012 10:33:52 +0200 [thread overview]
Message-ID: <4FAB7D70.1040704@nod.at> (raw)
In-Reply-To: <1336624000.1936.22.camel@brekeke>
[-- Attachment #1: Type: text/plain, Size: 2090 bytes --]
Hi Artem!
Am 10.05.2012 06:26, schrieb Artem Bityutskiy:
> Hi Richard, I would like to complain about the names again. I though I
> better give this feed back as soon as possible...
No problem. :)
> Firs of all, thanks for doing this, I will look closer, and I am very
> keen of merging this stuff once we are sure its design is good, allows
> for future extensions and is backward-compatible.
>
Yeah.
First of all, yes it's fully backward-compatible. It uses two new internal volume IDs
with compat = UBI_COMPAT_DELETE.
Old UBI implementations will delete the checkpoint and continue with scanning...
Regarding design, ubi_wl_get_peb() currently offers three types of data types.
UBI_LONGTERM, UBI_SHORTTERM and UBI_UNKNOWN. Do we really need them?
Checkpointing has a pool of unknown PEBs. This PEBs have to be scanned while attaching.
For now I had to create three pools (for UBI_LONGTERM, UBI_SHORTTERM and UBI_UNKNOWN).
This makes the whole thing complexer than needed.
It introduces also some nasty corner cases.
To make the review easier for you:
The most critical code path is scan_pool() -> process_pool_seb() -> update_vol().
It searches within a pool for PEBs which are no longer empty and scans them.
After that it updates the corresponding volume.
ubi_update_checkpoint() is also very important because it has to find
unused PEBs at the beginning of the MTD to place the super block.
> So may be just naming your stuff UBI2, having terms like "UBI2 format",
> would be the easiest? Then someone could make this to be UBI3. A
> documentation section could describe what UBI2 is and how it is
> different from UBI1 or just UBI.
Okay, got your point.
I think "fastmap" is a good name because I can also use it within the code.
So, while reviewing the code please keep s/checkpoint/fastmap/g and s/cp/fm/g in mind. ;-)
I like the UBI2 idea. UBI2 = UBI + fastmap.
After the UBI2/fastmap design is stable I will happily write a detailed design paper
for http://www.linux-mtd.infradead.org/doc/ubi.html.
Thanks,
//richard
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
next prev parent reply other threads:[~2012-05-10 8:34 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-09 17:38 [RFC v2] UBI: UBIVIS (aka checkpointing) support Richard Weinberger
2012-05-09 17:38 ` Richard Weinberger
2012-05-09 17:38 ` [PATCH 1/7] [RFC] UBI: Add checkpoint on-chip layout Richard Weinberger
2012-05-09 17:38 ` Richard Weinberger
2012-05-11 11:17 ` Artem Bityutskiy
2012-05-11 11:17 ` Artem Bityutskiy
2012-05-11 12:02 ` Richard Weinberger
2012-05-11 12:02 ` Richard Weinberger
2012-05-11 12:21 ` Artem Bityutskiy
2012-05-11 12:21 ` Artem Bityutskiy
2012-05-11 17:15 ` Richard Weinberger
2012-05-11 17:15 ` Richard Weinberger
2012-05-11 18:56 ` Artem Bityutskiy
2012-05-11 18:56 ` Artem Bityutskiy
2012-05-11 19:15 ` Richard Weinberger
2012-05-11 19:15 ` Richard Weinberger
2012-05-09 17:38 ` [PATCH 2/7] [RFC] UBI: Add checkpoint struct to ubi_device Richard Weinberger
2012-05-09 17:38 ` Richard Weinberger
2012-05-09 17:38 ` [PATCH 3/7] [RFC] UBI: Export next_sqnum() Richard Weinberger
2012-05-09 17:38 ` Richard Weinberger
2012-05-09 17:38 ` [PATCH 4/7] [RFC] UBI: Export compare_lebs() Richard Weinberger
2012-05-09 17:38 ` Richard Weinberger
2012-05-09 17:38 ` [PATCH 5/7] [RFC] UBI: Make wl subsystem checkpoint aware Richard Weinberger
2012-05-09 17:38 ` Richard Weinberger
2012-05-09 17:38 ` [PATCH 6/7] [RFC] UBI: Implement checkpointing support Richard Weinberger
2012-05-09 17:38 ` Richard Weinberger
2012-05-09 17:38 ` [PATCH 7/7] [RFC] UBI: wire up checkpointing Richard Weinberger
2012-05-09 17:38 ` Richard Weinberger
2012-05-10 4:26 ` [RFC v2] UBI: UBIVIS (aka checkpointing) support Artem Bityutskiy
2012-05-10 4:26 ` Artem Bityutskiy
2012-05-10 8:33 ` Richard Weinberger [this message]
2012-05-10 8:33 ` Richard Weinberger
2012-05-11 10:46 ` Artem Bityutskiy
2012-05-11 10:46 ` Artem Bityutskiy
2012-05-11 10:49 ` Richard Weinberger
2012-05-11 10:49 ` Richard Weinberger
2012-05-11 11:26 ` Artem Bityutskiy
2012-05-11 11:26 ` 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=4FAB7D70.1040704@nod.at \
--to=richard@nod.at \
--cc=Heinz.Egger@linutronix.de \
--cc=dedekind1@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=tglx@linutronix.de \
--cc=tim.bird@am.sony.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.