| 1 |
On Tue, 13 May 2014 07:55:56 +0200 Ulrich Mueller wrote: |
| 2 |
> >>>>> On Tue, 13 May 2014, Andrew Savchenko wrote: |
| 3 |
> |
| 4 |
> > Please consider that by default du shows block size, not byte size. |
| 5 |
> > Than means that if file is actually 1234 bytes large, without -b it |
| 6 |
> > will be still accounted for 4096 bytes on 4K-block filesystem. |
| 7 |
> |
| 8 |
> This raises another question, namely if files with <= 4096 bytes size |
| 9 |
> should be compressed at all? Portage already has a fixed size limit of |
| 10 |
> 128 bytes (see bug 169260), but maybe this could be made configurable. |
| 11 |
|
| 12 |
In no doubt this limit should be configurable, because defaults |
| 13 |
fine for one setup may harm another. |
| 14 |
|
| 15 |
If we are trying to consider all possible cases, some filesystems |
| 16 |
may benefit even from compression of very small files (e.g. from |
| 17 |
140 to 100 bytes) due to packing of multiple small files in the |
| 18 |
same inode. ReiserFS is a good example, but more may be somewhere |
| 19 |
there. |
| 20 |
|
| 21 |
If we are trying to consider a majority of users (and thus to |
| 22 |
select reasonable defaults), from disk usage + decompression |
| 23 |
overhead point of view it will be the best to store compressed files |
| 24 |
if they are at least one filesystem block smaller than original |
| 25 |
file. FS block size may be extracted runtime for any man or doc, or |
| 26 |
alike directory used, so this is doable. But this approach may |
| 27 |
overcomplicate implementation. |
| 28 |
|
| 29 |
Best regards, |
| 30 |
Andrew Savchenko |
Archives