JFFS3 memory consumption
Artem B. Bityuckiy
dedekind at infradead.org
Fri Jan 28 04:23:12 EST 2005
On Fri, 28 Jan 2005, Thomas Gleixner wrote:
> On Fri, 2005-01-28 at 08:45 +0000, Artem B. Bityuckiy wrote:
> > But my original proposal assumed we agree with that and was about a bit
> > another thing. The question was: do we really want to distinguish between
> > pritine nodes and non-pristine nodes.
>
> Yes.
>
> > Recall for those who do not remeber JFFS2 internals: pristine node is that
> > node which contains PAGE_SIZE (4K) bytes of data. These nodes may quicly
> > satisfy read request - just unpack the node's data to the page provided by
> > upper layer. Non-pristine nodes are those nodes which contain fewer then
> > PAGE_SIZE bytes of data or they may contain 4K of data, but be partially
> > overlapped by newer node with more actual data.
> >
> > My Idea is that having write-back cache a lot of writes will first go to
> > the cache, and we may just always write by 4K fractions. No more
> > not-pristine nodes. All nodes are now 4K or multiple of 4K.
>
> I disagree. Are you really trying to tell me that _ALL_ nodes are 4K
> size aligned ? Just look at your filesystem.
:-) I did not pretend to be correct.
>
> > Adwantages:
> > Simpler GC. Now we not need to merge non-pristine nodes. When Garbage
> > Collect one block, do not produce dirt in another block (because of
> > merging). GC is much faster. We do not need to iget() anymore when we meet
> > non-pristine node in GC.
>
> It's not simpler, because you have to take care of synchronous
> transactions.
Haven't get it what you means.
>
> > Drawbacks:
> > Yes, if we are forced to do synchronose IO, we well waste more space. For
> > example, user does 1 byte transactions, we write 4K instead every time.
> > But is this so bad?
>
> Yes, because it requires much more write/erase cycles and the
> performance will be worse than the current JFFS2.
>
> tglx
Ok. Convinced. We have to have two flavours of nodes - pristine and
non-pristine. Thanks.
--
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.
More information about the linux-mtd
mailing list