From what I've read, after I use chattr -R +c <dir>
the c flag is added and compression begins. And any file written to that directory afterward will automatically have the c flag added.

Also, next to the entry, it will show what type of compression was used (gzip,lzo, etc).

I've mounted my /home partition with the option user_xattr,

I've tried chattr on a few directories, and see the c flag has been added. It isn't added to new files written to the directory though, and it shows no compression method on any file when I use lsattr.

And using other utilities, I don't see any indication that compression took place.

I'm on Slackware 13.1 using vmlinuz-huge-smp-2.6.33.4-smp

Here is some output:

Unless I'm mistaken, the compression is transparent (inline), so you won't notice anything about the files when reading them or viewing their properties -unless you use lsattr. You might also make copies of a file or two and place them in the dir you use 'attr -c' on. Then compare the (hopefully compressed) files using du with and without the '--apparent-size' option.

1 members found this post helpful.

Checking the properties using pcmanfm
Total size of Files:
7.6 .cache/google-chrome/
7.7 temp

Size on Disk:
18.5 .cache/google-chrome/
19.7 temp

Well now, this is interesting....

Using rsync instead of cp to mirror the directory

After deleting temp and using cp again:
Radically different results using rsync; why might that be?

So, the compression appears to be working (though in this case I'm not gaining much). Thanks, gnashley.

That looks like over 50% savings which is quite good! Saviings with a buch of small files may not be as good as with larger files.

About rsync and pcmanfm, you have to realize that there is more than one way to determine the size of a file and most tools -especially file managers- will only use one method. To get the best idea of the savings, simply compare one or two representative files by using 'du' -first normally as you usually would. Then run it but add '--apparent-size' to the options. I have for a long time used (occassionaly) an ext2 modification called e2compr -it's a patch for the kernel, plus patched tools like findutils and e2fsprogs. The kernel patch makes the kernel recognize and transparently compress or decompress the files. The findutils and e2fsprogs patches make it possible to change the attributes of files and dirs and to search for such compressed files. The e2compr code never made it into the official ext2/ext3 code, but may have served as a base or idea for the current ext4 support for compression. I think it'S great because you just 'chattr' a directory and then everything you put in there gets compressed without any other steps.

I'm not sure whether the ext4 code is working the same way or not. with the old code, you had to use chattr *first* and then anything written there would be compressed -and you could undo the compression with chattr, if needed. Then files added would not be compressed -but the old ones would still remain compressed.

I found the ext2 support(old code) quite stable and gave results comparable with what you are seeing -in the range of 45-60% depending on the specific files. I still hope to see generic compression support (maybe at the VFS level) which would provide compression for any supported file system. If I understand correctly, btrfs is going to have or does have compression support.

About mirroring the directory contents -unless you use chattr to set the compression active for the new directory, the files should appear uncompressed in the new dir. Since the kernel decompresses them as they are read, tools like cp and rsync are receiving them already uncompressed.

1 members found this post helpful.

I didn't follow your instructions well the first time. I also didn't know about the --apparent-size option of du. Thanks for the lessons.

andy@pigeon:~$ du -sh --apparent-size ~/.cache/google-chrome/
24M /home/andy/.cache/google-chrome/
andy@pigeon:~$ du -sh ~/.cache/google-chrome/
20M /home/andy/.cache/google-chrome/

Just some extra info; compared it against two uncompressed directories.

From the du man page

Well, that doesn't seem to be much compression after all. Have you been able to find out what type of compression is being used? The old patches I worked with allowed for lzo, gzip or bzip2.

Most of the examples I've found were people using E2compr, and in the quote below, it illustrates that the compression used is shown next to the file name when using lsattr. But I don't have anything like that showing when I use lsattr myself. Specific to ext2? Outdated info? I really couldn't find much info in google using compression with an ext4 fs, and searches on the subject chattr or "chattr compress" brings up mostly manual pages.

http://linuxgazette.net/18/e2compr.html

The linuxgazette article is really old, but i nteresting beecause I had never run across it. e2compr is what I mentioned that I have worked with. There have been no updates now to the sourceforge site for wuite a while, but the some of the last work was done on porting e2compr to e3compr -for ext3 filesystems. Matthias Winkler is the current developer -I've had a bit of email contact with him before. For e3compr, he had trimmed the code considerably -taking out several of the compression types, which I thought made good sense. He talked to me about trying to implement a general VFS-level compressor -but it would be really hard to get such code into the mainstream kernel.

I'd like to see the current code modified to compile and run as en external kernel module -that would keep one from having to constatntly update the kernel patches to match new kernel versions. The e3compr version of the code may still be unusable -I need to get in contatc with Matthias again and see what the status is. Still, I am glad to see compression implemented in more than one of the filesystems available in the standard kernel.