All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matthew Gabeler-Lee <fastcat@gmail.com>
To: Richard Weinberger <richard.weinberger@gmail.com>
Cc: pratibha@codeaurora.org,
	"linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
	Artem Bityutskiy <dedekind1@gmail.com>,
	Ezequiel Garcia <ezequiel.garcia@free-electrons.com>,
	Tanya Brokhman <tlinder@codeaurora.org>
Subject: Re: [PATCH] mtd: nandsim: Allow nandsim to re-use persisted data
Date: Thu, 07 Nov 2013 12:36:19 -0500	[thread overview]
Message-ID: <527BCF93.6030207@gmail.com> (raw)
In-Reply-To: <CAFLxGvydWpQr_hMN8G=YViqgOOpJ=iSUu1sY0Eiurp-z=X55gQ@mail.gmail.com>

On 11/07/2013 10:12 AM, Richard Weinberger wrote:
> Hi!

Hi! Thanks for taking a look at this.  PS: First kernel patch I've ever
done...

> On Wed, Sep 25, 2013 at 9:25 PM, Matthew Gabeler-Lee <fastcat@gmail.com> wrote:
>> @@ -592,6 +595,9 @@ static int alloc_device(struct nandsim *ns)
>>                         err = -ENOMEM;
>>                         goto err_close;
>>                 }
>> +               if (cache_file_written) {
>> +                       memset(ns->pages_written, 0xFF, ns->geom.pgnum);
>> +               }
> 
> Hmm, that's a very ugly hack.
> It will slow down nandsim because now it will ask the file cache every time.
> 
> If you want persistent storage we'd need a sane file format with header
> which contains the page_written bitmask, the nand geometry, etc....

Agreed that it's a hack.  My thought process was to a) minimize the
changes and b) have the resulting persisted image be usable to write to
a real flash device, if that was desired.  I'm not sure if the OOB data
would make part b not actually work, though.  I agree that a real file
format (or split files) that tracks metadata would be better overall.
It would beg for some userspace tools to work with it.

As far as performance is concerned, if considering a real file format,
in my testing it appeared that the non-aligned writes resulting from the
OOB bytes may also have been a problem.  AFAICT my application (UBI/FS)
never actually accesses those OOB bytes, so getting creative with where
they are stored in a file format could have some benefits.

      reply	other threads:[~2013-11-07 17:36 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-25 19:25 [PATCH] mtd: nandsim: Allow nandsim to re-use persisted data Matthew Gabeler-Lee
2013-11-07 15:12 ` Richard Weinberger
2013-11-07 17:36   ` Matthew Gabeler-Lee [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=527BCF93.6030207@gmail.com \
    --to=fastcat@gmail.com \
    --cc=dedekind1@gmail.com \
    --cc=ezequiel.garcia@free-electrons.com \
    --cc=linux-mtd@lists.infradead.org \
    --cc=pratibha@codeaurora.org \
    --cc=richard.weinberger@gmail.com \
    --cc=tlinder@codeaurora.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.