All of lore.kernel.org
 help / color / mirror / Atom feed
From: Artem Bityutskiy <dedekind1@gmail.com>
To: Joel Reardon <joel@clambassador.com>
Cc: linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH V4] UBI: modify ubi_wl_flush function to clear work queue for a lnum
Date: Mon, 21 May 2012 14:41:34 +0300	[thread overview]
Message-ID: <1337600494.2483.67.camel@sauron.fi.intel.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1205202126480.29205@eristoteles.iwoars.net>

[-- Attachment #1: Type: text/plain, Size: 1484 bytes --]

On Sun, 2012-05-20 at 21:27 +0200, Joel Reardon wrote:
> This patch modifies ubi_wl_flush to force the erasure of
> particular volume id / logical eraseblock number pairs. Previous functionality
> is preserved when passing UBI_UNKNOWN for both values. The locations where ubi_wl_flush
> were called are appropriately changed: ubi_leb_erase only flushes for the
> erased LEB, and ubi_create_volume forces only flushing for its volume id.
> External code can call this new feature via the new function ubi_flush() added
> to kapi.c, which simply passes through to ubi_wl_flush().
> 
> This was tested by disabling the call to do_work in ubi thread, which results
> in the work queue remaining unless explicitly called to remove. UBIFS was
> changed to call ubifs_leb_change 50 times for four different LEBs. Then the
> new function was called to clear the queue: passing wrong volume ids / lnum,
> correct ones, and finally UBI_UNKNOWN for both to ensure it was finally all
> cleard. The work queue was dumped each time and the selective removal
> of the particular LEB numbers was observed. Extra checks were enabled and
> ubifs's integck was also run. Finally, the drive was repeatedly filled and emptied to
> ensure that the queue was cleared normally.

I've amended this patch to use UBI_ALL instead, and pushed to
linux-ubi.git tree, and in your branch as well. I'll send it to Linus
this merge window as well. Thanks!

-- 
Best Regards,
Artem Bityutskiy

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

      reply	other threads:[~2012-05-21 11:38 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-15  7:44 [PATCH V2] UBI: add ubi_lnum_purge function to clear work queue for a lnum Joel Reardon
2012-05-15 11:40 ` Artem Bityutskiy
2012-05-19  9:46   ` Joel Reardon
2012-05-19 10:47     ` Artem Bityutskiy
2012-05-19 10:52       ` Artem Bityutskiy
2012-05-20 11:10 ` [PATCH V3] UBI: modify ubi_wl_flush " Joel Reardon
2012-05-20 19:27   ` [PATCH V4] " Joel Reardon
2012-05-21 11:41     ` Artem Bityutskiy [this message]

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=1337600494.2483.67.camel@sauron.fi.intel.com \
    --to=dedekind1@gmail.com \
    --cc=joel@clambassador.com \
    --cc=linux-kernel@vger.kernel.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.