5

I'm trying to keep a bunch of plain text files compressed using the extended attribute option - c on a debian ppc64 system. I ran the following commands:

# mkfs.ext4 /dev/test/compressed # mount /dev/test/compressed /mnt/compressed/ # mkdir /mnt/compressed/some/txts/ # chattr +c /mnt/compressed/some/txts/ # df -l # cp /some/txts/* /mnt/compressed/some/txts/ # sync # df -l

To my surprise, the output of df -l tells me the files I copied weren't compressed at all. I also tried to mount the test file system with the option user_xattr and I tried creating it with mkfs.ext4dev, but neither worked. I also checked the output of the commands lsattr /mnt/compressed/some/txts/; every line has a c in it.

Did I miss something? How come the xattr option c doesn't work as expected?

Improve this question
0

1 Answer 1

Reset to default
5

Makes sense to have a look at the man page of the programs you use:

BUGS AND LIMITATIONS
The c', 's', andu' attributes are not honored by the ext2 and ext3 filesystems as implemented in the current mainline Linux kernels.

This is not supposed to mean "ext4 works" I guess.

Improve this answer
3
  • i did read the man page, and chattr comes from e2fsprogs a file system utilities supports Ext2/3/4, it just make me more confused. further more, if kernel did not support c option, should chattr return an error or something? Commented Apr 28, 2013 at 15:49
  • @pingz "Should" != "does" I guess. Commented Apr 28, 2013 at 16:03
  • @pingz As you noted yourself "every line has a c in it" chattr did it right, didn't fail. So why should it return an error? How is it supposed to know what the kernel will do with this information? On the other hand it would perhaps make sense for the kernel to return an error on trying to set this attribute. Commented Apr 28, 2013 at 16:35

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.