Subject: Re: MTD devices in NetBSD
To: Garrett D'Amore <firstname.lastname@example.org>
From: Bill Studenmund <email@example.com>
Date: 03/23/2006 13:05:21
Content-Type: text/plain; charset=us-ascii
On Thu, Mar 23, 2006 at 12:38:32PM -0800, Garrett D'Amore wrote:
> Bill Studenmund wrote:
> > On Thu, Mar 23, 2006 at 10:26:31AM -0800, Garrett D'Amore wrote:
> > =20
> >> Bill Studenmund wrote:
> > Can you read less than a block in these things?
> For NOR, absolutely. Many NOR systems are actually mapped *directly*
> into system memory. I presume this to be true (that you can read less
> than a sector, not the mapping bit) for NAND, but I confess I'm still
> largely ignorant of NAND.
Ok. This is important as it means that you can easily do sub-block reads.
> >> So, if the abstraction is going to use a smaller block size -- say 512
> >> bytes -- to get good allocation, we have other problems:
> >> For the rest of the discussion, lets assume a 64K sector size (the most
> >> common NOR flash size, I think):
> >> A naive implementation would make updating a sector an erase/modify
> >> cycle. Obviously this is bad, because writing (or updating) a 64K file
> >> now requires 128 erase cycles. Erase takes a long time, and wears down
> >> flash. This is unworkable.
> > Wait, I'm now confused. I thought we had one of three cases:
> > 1) we have a flash-unaware file system sitting on a flash. This would b=
> > intended as a r/o kinda thing to help with bring-up.
> > =20
> > 2) We have a flash-unaware file system on top of a wear-leveling layer =
> > the flash. This should work r/w.
> > =20
> I'm not necessarily proposing this. Others may be, but not me.
Understood. And I'm not saying you need to implement it. But I think it's=
easy to think about now. :-)
> > 3) We have a flash-aware file system sitting on a flash.
> > The case above isn't one of those three, so why do we care?
> I think we're misunderstanding each other. Updating a sector (for any
We probably are misunderstanding each other. :-)
> r/w case) where you modify less than the whole sector at once creates
> the problem. This happens in case #2 above. (And also case #3 if the
> flash aware system uses a block size !=3D sector size, and wants to update
> a large file. My understanding of strategy is that you only get one
> block at a time, not a list for the entire file.)
You get one "upper level" block at a time, for whatever that is. All of=20
the reasons for restricting the block sizes and alignments have to do with=
how the block cache works (it does not cope with aliasing).
My point is that the only time that we will do writes are ones (#2 or #3)=
where we have something that understands flash above us. So let's make it=
So it's perfectly reasonable for the strategy routine to handle reads of=20
whatever size it wants and to require that writes are aligned and sized to=
match the underlying device's block layout. Or you could also say that the=
strategy routine only handles reads and that writes & erases have to go=20
through an ioctl.
> > i'm still confused. :-) 1) I don't think a file system will really use=
> > 512-byte blocks internally. You'd have to specificaly set it, and I'm n=
> > sure it'd be worth it.
> > =20
> You need small blocks in any case (64k is too wasteful). Even at 8K
> you still have 8 read/modify cycles.
Ok, here's a key misunderstanding of mind. That's how normal file systems=
work. Why are we worrying about how normal file systems work on flash if=20
we all agree they work poorly? Either the normal file system is there=20
because you bulk-loaded it (makefs then a dd that matched block sizes on=20
flash) or it's a flash-aware writing layer that can do the caching and be=
sane about things. ??
> > I think you're painting yourself into corners we don't need to be trapp=
> > in.
> Possibly. But exposing the details rather than hiding them seems to me
> to be *avoiding* corners. If I hide sector and wear-leveling details
> behind some kind of meta-device or flash translation layer, then I fear
> it will limit choices that we can make otherwise.
I don't think so. The only significant hiding layer in this discussion, I=
think, is the wear-leveling layer. I think it's perfectly reasonable for a=
flash to attach (and have all the semantics other than wear-leveling we've=
discussed) then have a wear-leveler attach to that.
> > If the flash-unaware fs is only used in r/o mode, why do we need to wor=
> > about its write performance?
> We don't. But the flash-aware filesystem needs to have access to
> something other than blocks/strategy, I think.
As above, I think you can get a lot o mineage out of the strategy routine.=
But I partially suspect that I see it as a more flexible interface than I=
gather you do. :-) Other than explicit erase, I think it can easily do=20
what you want to do in the near term.
> > The, "It's HARD to solve the problem," reason is quite reasonable at=20
> > times, and this may well be one.
> Heh. Maybe. I'm trying to make the problem tractable, because I need
> to implement *something*, and soon.
I guess that's also part of my frustration. I genuinely do not think I'm
making more work for you! :-) To me it seems more like, "instead of
jumping left, foreward, left, right, right, right, jump right, foreward". =
If you think I'm making more work, one or both of us is misunderstanding=20
the other. :-) I freely admit it might be me. ;-)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)
-----END PGP SIGNATURE-----