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

Re: JFFS compression and hard links.



On Wed, 10 Jan 2001, David Woodhouse wrote:
> > The user space tool would need to be able to call a "compressed_write"
> > on a live mounted filesystem, but this should not be much different
> > than normal writes (which would be uncompressed).
> 
> Having a way for an application to get compressed nodes onto the flash at
> runtime isn't going to be simple. At least, it's not going to be _clean_.
> And that's what I care about.

The procedure I had in mind for the decompress-only runtime version was
that mkfs.jffs does the compression, jffs does the decompression, and a
user-mode tool is invoked to actually compress a file, given certain
criterias are met (that are too strict to be usable in runtime
compression).

Namely, the resulting compressed version need to fit in the free area in
the flash without the need for GC'ing, and still leaving 1.5 erase-blocks
free.

The user-mode program would freeze JFFS operations, check the criteria,
and if they are met, do the same thing mkfs.jffs does when compressing a
file (compress each page by itself and create jffs nodes) and store on
flash (using some ioctl or whatever). Then unfreeze JFFS.

After that, the state would be similar to after a normal mkfs.jffs
compress-once session, with no possibility of the GC getting upset.

I don't know how useful such a thing would be though. It is probably the
same thing as implementing GC-based late compression of nodes in files
with the 'dont compress' bit unset (or 'compress' bit set :) so if the
latter is easy, I guess that's how we should do it.

I still don't believe doing the compression at the first write is
good. It's better to do it during the GC run later, because then you have
all the options to handle the nodes in any way you want, AND importantly,
we know the initial write cannot screw up the GC later (we don't need that
formal proof of the compressability :)

-BW


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