On Tue, 13 May 2014 08:18:25 -0400 Rich Freeman wrote: > On Tue, May 13, 2014 at 7:01 AM, Andrew Savchenko <[email protected]> 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
pgpHZlB7ZRZ7U.pgp
Description: PGP signature
