All of lore.kernel.org
 help / color / mirror / Atom feed
From: Artem Bityutskiy <dedekind@infradead.org>
To: Alexander Schmidt <alexs@linux.vnet.ibm.com>
Cc: "linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>
Subject: Re: [MTD] UBI: Per volume update marker
Date: Thu, 25 Jan 2007 20:16:34 +0200	[thread overview]
Message-ID: <1169748994.9477.15.camel@sauron> (raw)
In-Reply-To: <200701241019.27470.alexs@linux.vnet.ibm.com>

Hi Alexander,

On Wed, 2007-01-24 at 10:19 +0100, Alexander Schmidt wrote:
> I am currently implementing a per volume update marker for UBI.
> It would be nice to know if you are interested in this feature and if you
> have remarks about my concept.
> 
> The main reason I see for implementing this feature is that the current update
> marker blocks updates to all volumes if the update marker is pending. So the
> user needs to interfere after an update has been interrupted. We saw this
> problem for example when mirroring volumes at boot time. Another point is
> that pending update markers on removed volumes are avoided. While reproducing
> this error case, i got some kernel panics from the current kernel.
> 
> My suggestion to solve these problems is to include a per volume update marker
> in the volume table (both in ram and on flash), and to let the user perform
> updates on all volumes, while still marking volumes with pending update
> markers as corrupted to avoid reading of corrupted/incomplete data. In my
> first implementation, I used a free (marked as "padding") byte in the volume
> table and added the function "ubi_vmt_updvol()" to volmgmt.c. This function
> gets called by the functions for starting and finishing updates with the
> appropriate flags and sets or removes the update marker from the volume
> table.


The patch in general (did not look closely to the details) looks good
for me. But are you sure you want this patch? It was a requirement from
your team to implement the update marker. Note, your patch means that
the boot-loader needs to read and interpret the volume table which
increases its size.

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

  reply	other threads:[~2007-01-25 19:00 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-01-24  9:19 [MTD] UBI: Per volume update marker Alexander Schmidt
2007-01-25 18:16 ` Artem Bityutskiy [this message]
2007-01-25 19:19   ` Josh Boyer
2007-01-26  8:47   ` Frank Haverkamp
2007-01-26 10:43     ` Artem Bityutskiy
2007-01-26  8:04 ` Artem Bityutskiy
2007-01-29 10:47   ` Alexander Schmidt
2007-01-29 13:02     ` Artem Bityutskiy
2007-01-29 16:36       ` Alexander Schmidt
2007-01-30 13:01         ` Artem Bityutskiy
2007-01-30 13:44         ` Artem Bityutskiy
2007-01-30 15:36         ` Artem Bityutskiy
2007-01-30 18:35         ` Artem Bityutskiy
2007-01-30 19:00         ` 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=1169748994.9477.15.camel@sauron \
    --to=dedekind@infradead.org \
    --cc=alexs@linux.vnet.ibm.com \
    --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.