From: David Woodhouse <dwmw2@infradead.org>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: "Jörn Engel" <joern@wohnheim.fh-wedel.de>,
"Miraj Mohamed" <miraj@procsys.com>,
jffs-dev@axis.com, linux-mtd@lists.infradead.org
Subject: Re: mirroring in JFFS2
Date: Tue, 12 Nov 2002 17:07:22 +0000 [thread overview]
Message-ID: <6310.1037120842@passion.cambridge.redhat.com> (raw)
In-Reply-To: <1037121749.8746.67.camel@irongate.swansea.linux.org.uk>
alan@lxorguk.ukuu.org.uk said:
> The fs doesnt know enough about the block I/O layer to do that
Certainly it doesn't when it's all hidden by RAID. It's feasible that it
_could_ though. It looked like the nwfs code did something like this -- you
told the file system explicitly about all the individual block devices it
was supposed to be using. I never did investigate it much though.
To be honest, in a lot of cases I'd settle for a way for a file system to
tell the block device 'this sector is now unused'. Not so much for RAID but
for the "block-based file system on flash translation layer" case.
> A dupfs layer is probably quite doable too yes.
There are a few interesting cases about what you do when you get write
errors (or -ENOSPC) after your write already succeeded to the other device,
but yeah -- it shouldn't be too horrible.
> However for JFFS2 surely all you actually want to do is write each log
> entry including its ID number to both journals. When you hit a bad block
> you can play back that bit of the journal from the other flash and then
> mark it bad.
Yep, that basically works.
> The only fun case is working out the size of your journal since its
> effectively the smaller of two journals can shrink online.
Well that bit is quite fun already :)
But it's not too bad -- you GC on _both_ media till you have enough space
on them both for the write you want to do, then you allow the allocation
call to return, do the write to both media and return. Some detail in
sorting out the case where a page write crosses an eraseblock boundary and
ends up split into two on one or both media, but that's not really too hard
conceptually -- I suspect it'd make an ugly mess of the code though.
--
dwmw2
next prev parent reply other threads:[~2002-11-12 16:37 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <3DD0D966.E6D877EC@procsys.com>
2002-11-12 16:08 ` mirroring in JFFS2 Jörn Engel
2002-11-12 16:18 ` David Woodhouse
2002-11-12 17:15 ` Jörn Engel
2002-11-12 17:22 ` Alan Cox
2002-11-12 17:07 ` David Woodhouse [this message]
2002-11-12 17:27 ` Jörn Engel
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=6310.1037120842@passion.cambridge.redhat.com \
--to=dwmw2@infradead.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=jffs-dev@axis.com \
--cc=joern@wohnheim.fh-wedel.de \
--cc=linux-mtd@lists.infradead.org \
--cc=miraj@procsys.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox