Messages in this thread | | | Date | Sun, 6 Feb 2000 14:18:49 +1100 | From | Peter Moulder <> | Subject | Re: kernel read/write question |
| |
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/
| |