From: David Woodhouse <dwmw2@infradead.org>
To: Chuck Meade <chuckmeade@mindspring.com>
Cc: linux-mtd@lists.infradead.org
Subject: RE: DOC filesystem questions
Date: Fri, 08 Aug 2003 08:30:34 +0100 [thread overview]
Message-ID: <1060327833.25209.271.camel@passion.cambridge.redhat.com> (raw)
In-Reply-To: <IIEEICKJLNEPBBDJICNGOEHCDMAA.chuckmeade@mindspring.com>
On Thu, 2003-08-07 at 17:56, Chuck Meade wrote:
> David Woodhouse wrote:
>
> > We _must_ retain the bad block table which was on the device when it
> > arrived from the factory.
>
> OK I see. Would it be valuable then to have a Linux command-line
> utility which captures the BBT before calling nftl_format, then
> is used to restore the BBT after calling nftl_format but before
> nftl tries to mount any partitions (via 'insmod nftl' or whatever)?
... or which writes it back as _part_ of the nftl_format process,
perhaps?
Yes, it would be extremely useful to do this.
> Since nftl_format can be called with an offset, I believe the utility
> would not necessarily put the BBT back at the exact device offset
> from which it was read. For instance, when reading the initial BBT
> we might find the media headers in the first 2 blocks on the device,
> and read/save the BBT from there. However, if nftl_format is called
> with an offset, we would need to write the saved BBT back to the
> device at the blocks with media headers written beyond that offset
> by nftl_format.
>
> Does such a utility for the Linux command line sound like it would
> preserve the BBT correctly?
>
> Thanks,
> Chuck
--
dwmw2
next prev parent reply other threads:[~2003-08-08 7:30 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-08-06 4:27 DOC filesystem questions Chuck Meade
2003-08-07 10:43 ` David Woodhouse
2003-08-07 16:09 ` Chuck Meade
2003-08-07 16:32 ` David Woodhouse
2003-08-07 16:56 ` Chuck Meade
2003-08-08 7:30 ` David Woodhouse [this message]
2003-08-08 13:42 ` Chuck Meade
2003-08-08 14:05 ` David Woodhouse
2003-09-19 22:27 ` Chuck Meade
2003-09-20 1:20 ` Chuck Meade
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=1060327833.25209.271.camel@passion.cambridge.redhat.com \
--to=dwmw2@infradead.org \
--cc=chuckmeade@mindspring.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox