public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
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

  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