From: David Woodhouse <dwmw2@infradead.org>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: nico@cam.org (Nicolas Pitre), jgg@ualberta.ca (Jason Gunthorpe),
bjorn.wesen@axis.com (Bjorn Wesen),
jffs-dev@axis.com, mtd@infradead.org
Subject: Re: garbage collect
Date: Mon, 03 Jul 2000 17:09:38 +0100 [thread overview]
Message-ID: <21897.962640578@cygnus.co.uk> (raw)
In-Reply-To: <E1397tM-0004tu-00@the-village.bc.nu>
alan@lxorguk.ukuu.org.uk said:
> The interesting question is should they.
I don't (currently) think so. It's fairly difficult to fit flash into the
block device model.
JFFS is the primary user of MTD devices now - everything else (i.e. FTL,
NFTL) is a second class citizen. JFFS writes variable-size nodes, and doing
that on a block device would mean wasting RAM on grouping writes into
blocksized chunks.
And what do you set your blocksize to? On most NOR flash devices, it's
something like 128Kb. We need to support sub-blocksize writes, and we need
that to be explicitly controlled by the user, so it can optimally balance the
journalling requirements with the desire to have as few write cycles as
possible.
> Withouth them going via the block layer you wont be able to mirror
> them
Mirrored flash? That's just sick. And anyway, it needs to be done at a
higher level than the individual flash chips - on which you may have bad
blocks in different places, which need to be mapped round differently on
each chip.
Currently, if you want mirrored flash, you have to use {N,}FTL to provide
emulated block devices on top of which you stick your RAID array.
It's feasible to add direct mirroring support to JFFS, though, if it's
really a necessary feature.
> or potentially run a loopback fs over them soon
That's even sicker, and should arguably be done in userspace with nbd.
--
dwmw2
To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org
next prev parent reply other threads:[~2000-07-03 16:05 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <Pine.LNX.3.96.1000628091427.16453B-100000@wakko.deltatee.com>
2000-06-28 16:05 ` garbage collect David Woodhouse
2000-06-28 16:34 ` Jason Gunthorpe
2000-06-28 16:44 ` David Woodhouse
2000-06-28 18:20 ` Nicolas Pitre
2000-06-28 18:54 ` David Woodhouse
2000-06-28 19:33 ` Nicolas Pitre
2000-06-29 11:39 ` David Woodhouse
2000-06-29 15:06 ` mtdblock interface Nicolas Pitre
2000-07-03 15:12 ` garbage collect Alan Cox
2000-07-03 16:09 ` David Woodhouse [this message]
2000-07-14 11:05 ` David Woodhouse
[not found] <394F7351.BC878E0D@auriga.ru>
2000-06-20 14:16 ` dwmw2
2000-06-21 8:06 ` Nick Ivanter
2000-06-23 9:39 ` David Woodhouse
2000-06-23 9:49 ` Nick Ivanter
[not found] ` <394F88B3.1C046375@matrox.com>
2000-06-21 8:37 ` Nick Ivanter
2000-06-21 8:43 ` Nick Ivanter
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=21897.962640578@cygnus.co.uk \
--to=dwmw2@infradead.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=bjorn.wesen@axis.com \
--cc=jffs-dev@axis.com \
--cc=jgg@ualberta.ca \
--cc=mtd@infradead.org \
--cc=nico@cam.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