Axis log based flash filesystem ported to 2.3 and MTD

Axis log based flash filesystem ported to 2.3 and MTD

[Alexander Larsson]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 468 bytes --]

Hi, I've started porting the Axis journaling flash file system to
2.3.99-pre3 and mtd. It is still very much work in progress, but read
operation and inode modifications work.

This filesystem is really needed since the ftl layer has patent problem
and this one seems totally free.

Just unpack the tarball in the mtd tree.

David, can you check this in?

I will continue chip away on this until it works. I'll also try to clean
up mtd a bit, as time permits.

/ Alex

[-- Attachment #2: Type: APPLICATION/octet-stream, Size: 37196 bytes --]

Re: Axis log based flash filesystem ported to 2.3 and MTD

[David Woodhouse]

Forgive me for reposting private mails to the list, but it seems that some 
introductions are in order....

alex@cendio.se said (re Axis' JFFS):
>  This filesystem is really needed since the ftl layer has patent
> problem and this one seems totally free. 

sanders@mvista.com said:
>  From what little I understand about the M-systems' patent, it
> basically patented the idea of using an array to do the translation
> and I would guess that Axis' work would violate that.

kwonsk@mutech.co.kr said:
> If i could not use FTL layer on the direct flash chip under GPL, then
> what mtd Layer (FFS from MS?) should i choose without license
> problems?

I'm not really sure about the patent issues - I'm just glad I live in the Free
World (for now). It's probably best discussed on the list than in private mail 
with my clueless self.

(To subscribe to the list, send "subscribe mtd" in the body of a mail to 
majordomo@infradead.org)


--
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: Axis log based flash filesystem ported to 2.3 and MTD

[Alexander Larsson]

On Mon, 27 Mar 2000, David Woodhouse wrote:

> Forgive me for reposting private mails to the list, but it seems that some 
> introductions are in order....
> 
> alex@cendio.se said (re Axis' JFFS):
> >  This filesystem is really needed since the ftl layer has patent
> > problem and this one seems totally free. 
> 
> sanders@mvista.com said:
> >  From what little I understand about the M-systems' patent, it
> > basically patented the idea of using an array to do the translation
> > and I would guess that Axis' work would violate that.

While i haven't read the M-systems patent I think the Axis fs doesn't
violate it, because it uses no translation array. It is a fully
log-structured filesystem directly on the flash memory, and not a flash to
block device translator.

/ Alex





To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: Axis log based flash filesystem ported to 2.3 and MTD

[Scott Anderson]

Alexander Larsson wrote:
> While i haven't read the M-systems patent I think the Axis fs doesn't
> violate it, because it uses no translation array. It is a fully
> log-structured filesystem directly on the flash memory, and not a flash to
> block device translator.

Let me give a bit more background.  I have *not* looked at Axis' filesystem
so my "guesses" should not be viewed as authoritative.  Figuring out the
patent implications was something that I hadn't yet gotten around to yet.

Thanks to Alexander, I may not have to.  I'm under the impression that Axis'
file system implements wear-leveling, so if there isn't an FTL, then the
file system itself must rotate through free blocks to prevent a given sector
from being worn out.  Is this correct?  If not, would you mind educating me?

Thanks!

    Scott Anderson		
    scott_anderson@mvista.com	MontaVista Software Inc.
    (408)328-9214		490 Potrero Ave.
    http://www.mvista.com	Sunnyvale, CA  94086


To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: Axis log based flash filesystem ported to 2.3 and MTD

[Alexander Larsson]

On Mon, 27 Mar 2000, Scott Anderson wrote:

> Alexander Larsson wrote:
> > While i haven't read the M-systems patent I think the Axis fs doesn't
> > violate it, because it uses no translation array. It is a fully
> > log-structured filesystem directly on the flash memory, and not a flash to
> > block device translator.
> 
> Let me give a bit more background.  I have *not* looked at Axis' filesystem
> so my "guesses" should not be viewed as authoritative.  Figuring out the
> patent implications was something that I hadn't yet gotten around to yet.
> 
> Thanks to Alexander, I may not have to.  I'm under the impression that Axis'
> file system implements wear-leveling, so if there isn't an FTL, then the
> file system itself must rotate through free blocks to prevent a given sector
> from being worn out.  Is this correct?  If not, would you mind educating me?

Since it is log-based wear-leveling is automatically built-in. Think of
it as a circular buffer. When it is full, data is compacted from the tail
of the log and put on the head.

/ Alex




To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: Axis log based flash filesystem ported to 2.3 and MTD

[Bjorn Wesen]

On Mon, 27 Mar 2000, Scott Anderson wrote:
> Thanks to Alexander, I may not have to.  I'm under the impression that Axis'
> file system implements wear-leveling, so if there isn't an FTL, then the
> file system itself must rotate through free blocks to prevent a given sector
> from being worn out.  Is this correct?  If not, would you mind educating me?

The flash is not divided into blocks in our JFFS. The flash is logically a
single circular append-only file (but with random access of course).
Wear-leveling comes implicitely in that model, since the log-file is
circular.

The only way the flash's sector-coarseness comes into view, is when areas
not in use anymore need to be reclaimed - the garbage collector can only
reclaim if an entire sector is unused (or contains redundant information).

We're in the process of writing a white-paper about this. The concept is
extremely simple; the implementation is not always as simple :) 

-Bjorn



To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: Axis log based flash filesystem ported to 2.3 and MTD

[David Woodhouse]

bjorn.wesen@axis.com said:
>  The flash is not divided into blocks in our JFFS. The flash is
> logically a single circular append-only file (but with random access
> of course). Wear-leveling comes implicitely in that model, since the
> log-file is circular. 

When you append to your circular log, you end up eating your tail. What if the 
erase block you're about to 'eat' doesn't contain any data that needs to be 
changed. Do you leave it alone and skip it, or do you erase it anyway?

--
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: Axis log based flash filesystem ported to 2.3 and MTD

[Bjorn Wesen]

On Mon, 27 Mar 2000, David Woodhouse wrote:
> >  The flash is not divided into blocks in our JFFS. The flash is
> > logically a single circular append-only file (but with random access
> > of course). Wear-leveling comes implicitely in that model, since the
> > log-file is circular. 
> 
> When you append to your circular log, you end up eating your tail. What if the 
> erase block you're about to 'eat' doesn't contain any data that needs to be 
> changed. Do you leave it alone and skip it, or do you erase it anyway?

The garbage-collector is invoked when the amount of headroom starts to get
low compared to the amount of redundant areas in the flash. It will start
to erase sectors, and if they contain non-redundant info, it is moved to
the head first. Finn can fill in here in more detail.

As you see it's important that the GC is triggered at the right time. If
you end up with 1 byte head-room before the GC, you cannot move data out
of the way of the sector-erase. 

The parameters of the GC are chosen so they work for us, but they are
subject to tuning of course.

-Bjorn




To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: Axis log based flash filesystem ported to 2.3 and MTD

[Finn Hakansson]

On Mon, 27 Mar 2000, Bjorn Wesen wrote:

> On Mon, 27 Mar 2000, David Woodhouse wrote:
> > >  The flash is not divided into blocks in our JFFS. The flash is
> > > logically a single circular append-only file (but with random access
> > > of course). Wear-leveling comes implicitely in that model, since the
> > > log-file is circular. 
> > 
> > When you append to your circular log, you end up eating your tail. What if the 
> > erase block you're about to 'eat' doesn't contain any data that needs to be 
> > changed. Do you leave it alone and skip it, or do you erase it anyway?
> 
> The garbage-collector is invoked when the amount of headroom starts to get
> low compared to the amount of redundant areas in the flash. It will start
> to erase sectors, and if they contain non-redundant info, it is moved to
> the head first. Finn can fill in here in more detail.
> 
> As you see it's important that the GC is triggered at the right time. If
> you end up with 1 byte head-room before the GC, you cannot move data out
> of the way of the sector-erase. 

Yes. There must always be enough room to perform garbage collects. The
room absolutely needed in JFFS is more than 1,5 sectors. This means
that at least 1,5 sectors of the flash device are unused.

Before every write to the flash, we make sure there is enough space
left on the device. Deletions are always allowed though.

After every completed write to the flash we check if we have to issue
a garbage collect.


> The parameters of the GC are chosen so they work for us, but they are
> subject to tuning of course.

There is a function in JFFS called jffs_garbage_collect which contains
the criteria for garbage collects that, for the moment, suit our
products. As Björn stated, this function could be used as is, but could
of course be tuned to fulfil slightly different requirements.

/Finn



To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

JFFS mailing-list

[Bjorn Wesen]

We have a mailing-list for JFFS development. Send mail to
majordomo@axis.com with "subscribe jffs-dev" in the body, to join.

Since the flash interface and the filesystem are two different things, I
think it's best to discuss JFFS internals on that list. But you're welcome
to cc mtd of course as well for issues concerninc both JFFS and the flash
stuff.

-Bjorn


To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org