[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: garbage collect
> I don't really want partitions, I just want the FS to not touch the first
> erase sector if there is no FS data there. This is very much like how
> FAT/EXT2 reserve the first little bit of their devices for boot loaders.
you really want partitions :)
i mean its obvious that it would be simple to hardcode into JFFS to never
use the first sector in a partition, but that would work for some users
and be a complete waste for others (like if you have 4 JFFS partitions on
a flash, you'd waste at least 3 of the valuable sectors - you really dont
get that problem on FAT/EXT2 since they have small blocks)
like in our products, we define (hardcoded in the driver to make it
"foolproof") the first flash-sector to be read-only. it can be used for
factory stuff, and would never be erased or changed. it also contains boot
rescue code and stuff..
> Actually, with JFFS you could just store a special header node that has
> the file system meta data. Start/stop location, creation date, UUID, etc.
one of the design goals is to make it work on a completely empty
partition, so no headers etc are necessary. they could be optional though.
actually you can do this now - just write your header where you want it -
JFFS scan will find it and ignore it since it is not a JFFS node. it will
be erased when the sector is erased next time around the flash though :)
> > I think you lost me here - what is a "spare block" ?
> The spare block is the block you have to keep set aside so that you can
> use it in the GC process. When you want to compact a block (or in your
> case, erase a block) you first erase your spare block then transfer the
> data from the block you are going to erase into the spare then arrange for
> the old block to be discarded. You have to do this to advoid lossage if
> the power is shut off during a GC operation. (you cannot read the block
> you want to erase into ram, then compact it and write it out again!)
Ok. It is true that you need enough space at the log-tail to be able to
run a GC pass. We just don't use the terminology with "spare block" -
since it does not need to be a block, it just needs to be enough bytes
free to cover at least the non-redundant bytes in the head-block (or as we
want it to be later, one of the blocks).
> If the power is shut off in the middle of one of your GC's then you will
> have no clear spare and a block that is half populated from the GC
> operation, presumably with higher sequence numbers on your nodes..
> So how do you recover from a GC operation that is interrupted in the
> middle of repopulating the block that was just erased?
> You *must* have some way to discover this half written/erased block and
> force its use in the next GC cycle..
In JFFS, a garbage-collect does not do any operations that normal VFS ops
don't do. Thus the GC itself is covered by the journalling and cannot
break *provided enough space is available in the flash*.
In your scenario, if the power is cycled as the GC is moving nodes, then
the last moved node will be corrupt and not be used in the scan. When the
subsequent GC pass is run, it will just keep moving nodes to the place
after the last corrupt node (is this what you mean by "force its use in
the next GC cycle" ?)
Any half-written nodes (either by GC or VFS) are detected at scan and
As a side-effect, any sector that contains fully redundant info, is
scheduled for erasure (an operation that does not need to be atomic).