| 1 |
On Tue, May 13, 2014 at 7:01 AM, Andrew Savchenko <bircoph@×××××.com> wrote: |
| 2 |
> |
| 3 |
> If we are trying to consider all possible cases, some filesystems |
| 4 |
> may benefit even from compression of very small files (e.g. from |
| 5 |
> 140 to 100 bytes) due to packing of multiple small files in the |
| 6 |
> same inode. ReiserFS is a good example, but more may be somewhere |
| 7 |
> there. |
| 8 |
> |
| 9 |
|
| 10 |
Btrfs also supports file inlining, so every byte saved on small files |
| 11 |
does actually help (I believe the data structure that stores the |
| 12 |
inlined data doesn't have a fixed record size). Then again, btrfs |
| 13 |
also supports lzo compression and I believe this is fairly widely |
| 14 |
used, so I'm not sure that the impact of not compressing small files |
| 15 |
will be felt. |
| 16 |
|
| 17 |
I don't think ext4 supports inlining, but I see some discussions of |
| 18 |
attempts to add it. |
| 19 |
|
| 20 |
For VERY small files I would think that overhead would become an issue. |
| 21 |
|
| 22 |
Unless we have a bunch of 30-byte man pages I'd think that both |
| 23 |
simplicity and some potential for utility would lead us to use the |
| 24 |
best algorithm possible. |
| 25 |
|
| 26 |
Rich |
Archives