GC operation
Bernhard Priewasser
priewasser at gmail.com
Wed Nov 9 08:23:51 EST 2005
Hi Artem,
> So, the problem is that you think the code is not understandable? Offer
> your changes then.
No, the problem is that it's not always understandable for ME, that's a
big difference :-)
> Suppose we have an almost full partition. You write N bytes. There is
> only M free space, M < N. If there is N-M of dirty space, GC is started.
> Otherwise, -ENOSPC. GC will work until there is enough space to write.
> No need to GC the whole partition... Only if the dirty space is
> distributed over it, then yes. And yes, the more data is on the FS, the
> less is the GC performance and the greater is the average latency...
>
> Or, since blocks to GC are picked randomly, we may end up with GC of the
> whole partition, hypothetically, but unlikely.
OK. Things become more clearly. A write request to an almost full
partition always issues garbage collecting just as much space (nodes)
which is neccessary for writing the new data? And full GC is performed
only at mount? (And if c->resv_blocks_gctrigger is reached?)
>> jffs2_erase_pending_blocks(), am I right? When is it called? I can only
>> find it in jffs2_write_super() with count=0 and jffs2_find_nextblock()
>> with count=1.
> So, you've answered your question :-)
I meant the way it is called by kupdated (which I don't know at all).
> HTH,
It did! Thank you for patience.
--
Bernhard
More information about the linux-mtd
mailing list