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

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.

	- 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.

	- 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.

-- 
dwmw2



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