[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: JFFS compression and hard links.

-----Original Message-----
From: David Woodhouse <dwmw2@xxxxxxx.org>
To: Erwin Authried <eauth@xxxxxxx.at>
Cc: jffs-dev@xxxxxxx.com>
Date: Wednesday, January 10, 2001 13:25
Subject: Re: JFFS compression and hard links.

>On Wed, 10 Jan 2001, Erwin Authried wrote:
>> That may be true for *many* systems. Actually, the flash write speed
>> depends on the kind of flash chip that you are using, and compression
>> is highly CPU dependent. The (16-bit) word programming time is <10us
>> for many flash chips. I doubt that you can do compression that fast on
>> the Dragonball with 16 MHz, for example.
>OK, we definitely need the option of selecting whether run-time
>compression is performed.
>How about:
> - 'compress' bit on files to say whether they're to be
> compressed or not.
> - 'compress' bit on directories to control the default
> 'compress' state of new files therein.

We could consider the following as mount options instead of compile time
And compression should of course only take place if it makes sense to do it,
compressing .gif, .jpeg and .tgz might not be worth the effort.
To consider: Should we always compress and then see if we should write the
compressed or uncompressed version, or should the filesystem be "smart".

> - Compile-time option to disable runtime compression,
> resulting in immutable╣ semantics for compressed files.
> - Possible compile-time option for lazy compression - compress
> only at GC time, not at write time.
> - Possible compile-time option to disable runtime decompression,
> resulting in compressed files being unreadable.

Or giving you the compressed data for later decompression?

> - ioctl() handler for JFFS_IOC_[GS]ETFLAGS ({ls,ch}attr).
> chattr -c will decompress files, in all versions
> supporting decompression.
> chattr +c will compress files, only in the version
> which supports compression.
>Do we really need an option which supports chattr +c but doesn't do
>runtime compression?
>╣ actually this only need to be append-only. No reason why we can't add
>uncompressed nodes to the end of compressed files. But it's a corner case
>so I'm inclined to do what's easiest, which will be to deny writes if
>there are any compressed nodes.


To unsubscribe from this list: send the line "unsubscribe jffs-dev" in
the body of a message to majordomo@xxxxxxx.com