public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: "Artem B. Bityutskiy" <dedekind@yandex.ru>
To: Charles Manning <manningc2@actrix.gen.nz>
Cc: linux-mtd@lists.infradead.org
Subject: Re: Some JFFS3 feedback
Date: Wed, 16 Nov 2005 17:02:12 +0300	[thread overview]
Message-ID: <437B3BE4.1000902@yandex.ru> (raw)
In-Reply-To: <200511161024.00999.manningc2@actrix.gen.nz>

Hello Charles,

Charles Manning wrote:
> I briefly read the JFFS3 doc, and will read it more. It has some very 
> interesting ideas in it.
thanks for your feedback.

> About 9 years back, I did some flash file system patent research and IIRC one 
> of the patents covered something very similar to the Wandering Tree approach 
> to addressing the write-in-place problem, so there might be some IP issues 
> with this. I shall have a scratch around to see if I can find it (though 
> finding something in a 20+ year old paper mountain is a challenge).
Hmm, it is interesting. We would be very appreciated if you provide some 
information.

> I will be interested to see how you tackle the dreaded garbage collection. 
> IMHO, GC is something that needs to be considered sooner rather than later 
> because it is key to sustained write performance.
Absolutely. Me and my workmate in OktetLabs are thinking on this. At the 
moment we're considering 2 approaches. It seems there are no fundamental 
problems, but it needs more thinking, analisys and evaluation. We're 
even going to  create a user-level prototype to see how well (and fast) 
will GC work. Only after I have a clear picture in my mind I'm able to 
put it clearly in the paper.

But we anyway are not going to start implementation befor we've designed GC.

> I know that it is hard to change a name, but JFFS3 is really not much like 
> JFFS2 or JFFS in design, so keeping a similar name really gets confusing 
> later on (I get enough problems with yaffs and yaffs2 and they share 90% of 
> the code). I would suggest a name change to avoid confusion down the track.
Hmm, frankly, I think we may consider JFFS3 as an JFFS2's descendant. 
Yes, the code is probably going to be completely different. But try to 
glance to JFFS3 like this: it is just JFFS2 + on-flash indexing. JFFS2 
keeps indexing in RAM, we are going to keep it on Flash. Glance at 
figure 5 here: 
http://www.linux-mtd.infradead.org/tech/JFFS3design/node8.html.

But if there are some other good names and people are really bothered by 
the JFFS3 name - we might rename it as well.

-- 
Best Regards,
Artem B. Bityutskiy,
St.-Petersburg, Russia.

  reply	other threads:[~2005-11-16 14:03 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-11-15 21:24 Some JFFS3 feedback Charles Manning
2005-11-16 14:02 ` Artem B. Bityutskiy [this message]
2005-11-16 17:06   ` Jörn Engel
2005-11-18  0:15     ` Charles Manning
2005-11-22  6:21     ` Charles Manning
2005-11-22  7:22       ` Jörn Engel

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=437B3BE4.1000902@yandex.ru \
    --to=dedekind@yandex.ru \
    --cc=linux-mtd@lists.infradead.org \
    --cc=manningc2@actrix.gen.nz \
    /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