Re: [gentoo-dev] RFC: using .xz for doc/man/info compression

[Andrew Savchenko]

On Tue, 13 May 2014 08:18:25 -0400 Rich Freeman wrote:
> On Tue, May 13, 2014 at 7:01 AM, Andrew Savchenko <bircoph@×××××.com> wrote:
> >
> > If we are trying to consider all possible cases, some filesystems
> > may benefit even from compression of very small files (e.g. from
> > 140 to 100 bytes) due to packing of multiple small files in the
> > same inode. ReiserFS is a good example, but more may be somewhere
> > there.
> >
>
> Btrfs also supports file inlining, so every byte saved on small files
> does actually help (I believe the data structure that stores the
> inlined data doesn't have a fixed record size).  Then again, btrfs
> also supports lzo compression and I believe this is fairly widely
> used, so I'm not sure that the impact of not compressing small files
> will be felt.

I did not meant inlining. I was talking about block suballocation
which allows to store small files in underused blocks of another
files:
http://en.wikipedia.org/wiki/Block_suballocation

> I don't think ext4 supports inlining, but I see some discussions of
> attempts to add it.

Ext4 supports inlining for files up to 59 bytes:
https://ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout#Inline_Data
 
> For VERY small files I would think that overhead would become an issue.
>
> Unless we have a bunch of 30-byte man pages I'd think that both
> simplicity and some potential for utility would lead us to use the
> best algorithm possible.

Agreed, though performance should be considered still. I doubt
paq8l -9 will be used for this task, though it is about 1.5 times
more effective than xz -9e on text files, even on small ones like
man pages; on large files it is at least 2 times better.

Best regards,
Andrew Savchenko