On Fri, Feb 04, 2000 at 01:29:45PM -0800, Christopher A. Baumbauer wrote:
> I would like to thank Stephen, Laslo and Andreas for
> the links and info about e2compr, but I already knew
> about the patch. If I understand the patch correcly,
> it works by setting a permission bit to determine if a
(actually an ext2 file attribute bit -- chattr +c -- rather than a
permission bit)
> file is to be compressed, and if the file is a
> directory, then all new files
^^^^^^^^^^^^^^^^^^^^^^^^^
[insert, for clarification:] created in that directory
> are compressed. (If I'm wrong, let me know.)
Sounds about right. Also (again, just for clarification), any new directories
inherit the compression settings of the directory in which they were created;
so once you do `chattr +c /usr/{share/,}doc/.', any new packages you install will
automatically have their doc directory and contents compressed, without you having
to think about it.
> My intention is to mount a filesystem where everything is compressed,
> except for the files already compressed.
If you do `find MOUNTPOINT -type d -print0 | xargs -0r chattr +c' with
e2compr, then all files created in the filesystem from then on will be
compressed. If instead you do `find MOUNTPOINT \( -type d -o -type f \)
-print0 | xargs -0r chattr +c' (which I think is equivalent to `chattr -R
+c MOUNTPOINT'), then all the existing files will also be compressed, and
subsequent writes to all files will be compressed.
> An example would be a directory or file move and having it already
> compressed without having to set additional bits or remembering to set
> the compression bit each time I mount a disk.
I don't really understand the example. e2compr doesn't require that one does
anything special each time one mounts a disk; the compression settings are
stored in the flags word of the inode, so are persistent across remounts.
If you move (with mv) a file or directory around within a given filesystem,
its compression status is not affected by the move, since mv and ln affect
only the containing directory/s, not the inode of the moved file/directory.
If, on the other hand, you move a file from one filesystem to another,
then mv behaves like cp -a (followed by rm), so the behavior is as if you
were creating a new file in the destination directory (i.e. the file
inherits the compression settings of the destination directory).
(Another clarification for other readers: directories themselves are never
compressed (since directories have more to lose if the power goes off mid
way through an update); the compression settings stored with a directory
inode are used only for the inheritance mentioned above. When I say
inheritance, think BSD directory group ids, not object orientation.)
I suspect you may have been confused by poorly worded documentation
(which I wrote; nice to see that someone is reading it, anyway!). If that
is the case, then I'll try to fix that part.
Back to your original question about where de/compression should go:
e2compr takes the readpage/writepage approach. Another approach might be
to use CODA hooks; this is the approach taken by Pavel Machek's podfuk
(http://atrey.karlin.mff.cuni.cz/~pavel/podfuk/podfuk.html). Yet another
way is to create an intermediate block device, sort of like the loop block
driver; this is what Jean-Marc Verbavatz' DouBle does
(http://perso.cybercable.fr/~verbavat/double/).
I'd like to look more at the user-space option (coda or similar). It's more
robust against kernel changes (which reduces maintenance); it means that your
compression buffers can be swapped out; less kernel code tends to lead to a
more reliable kernel; and (hence) it's easier to be more sophisticated.
However, I'd agree with Stephen: you should look long and hard at e2compr
(or some other tool; I like e2compr because it's the most transparent of
the read-write compression options around for Linux) before trying to do
something else. Adding compression to a filesystem is a serious undertaking,
especially if you want it (including associated user-space tools) to be
usable and transparent enough that it can be included in the standard
kernel to be used by the masses. If you do want to spend significant time
on either e2compr or any other approach you think of that will achieve
e2compr's aims in less time than e2compr will, then I'll support you in
that work.
pjm.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Feb 07 2000 - 21:00:13 EST