| 1 |
On Tue, Aug 14, 2012 at 3:17 PM, Michael Mol <mikemol@×××××.com> wrote: |
| 2 |
> On Tue, Aug 14, 2012 at 3:55 PM, Alecks Gates <alecks.g@×××××.com> wrote: |
| 3 |
>> |
| 4 |
>> On Tue, Aug 14, 2012 at 12:50 PM, Michael Hampicke <gentoo-user@××××.biz> |
| 5 |
>> wrote: |
| 6 |
>> > Am 14.08.2012 19:42, schrieb Volker Armin Hemmann: |
| 7 |
>> >> Am Dienstag, 14. August 2012, 13:21:35 schrieb Jason Weisberger: |
| 8 |
>> >>> Sure, but wouldn't compression make write operations slower? And |
| 9 |
>> >>> isn't he |
| 10 |
>> >>> looking for performance? |
| 11 |
>> >> |
| 12 |
>> >> not really. As long as the CPU can compress faster than the disk can |
| 13 |
>> >> write |
| 14 |
>> >> stuff. |
| 15 |
>> >> |
| 16 |
>> >> More interessting: is btrfs trying to be smart - only compressing |
| 17 |
>> >> compressible |
| 18 |
>> >> stuff? |
| 19 |
>> >> |
| 20 |
>> > |
| 21 |
>> > It does do that, but letting btrfs check if the files are already |
| 22 |
>> > compressed, if you know, that they are compressed, is a waste of cpu |
| 23 |
>> > cycles :) |
| 24 |
>> > |
| 25 |
>> |
| 26 |
>> Also look into the difference between compress and compress-force[0]. |
| 27 |
>> I wonder how much overhead checking whether or not to compress a file |
| 28 |
>> costs. I use mount options similar to Helmut and get great results: |
| 29 |
>> defaults,autodefrag,space_cache,compress=lzo,subvol=@,relatime |
| 30 |
>> |
| 31 |
>> But most of my data is compressible. Compression makes such a huge |
| 32 |
>> difference, it surprises me. Apparently on this Ubuntu system it |
| 33 |
>> automatically makes use of all files on / as a subvolume in "@". |
| 34 |
>> Interesting. |
| 35 |
> |
| 36 |
> |
| 37 |
> Huge difference, how? |
| 38 |
> |
| 39 |
> Could we see some bonnie++ comparisons between the various configurations |
| 40 |
> we've discussed for ext4 and btrfs? Depending on the results, it might be |
| 41 |
> getting time for me to take the plunge myself. |
| 42 |
> |
| 43 |
> -- |
| 44 |
> :wq |
| 45 |
|
| 46 |
Check out some of the benchmarks on Phoronix[0]. It's definitely not |
| 47 |
a win-win scenario, but it seems to be great at random writes and |
| 48 |
compiling. And a lot of those wins are without compress=lzo enabled, |
| 49 |
so it only gets better. I'm not going to say it's the absolute best |
| 50 |
out there (because it isn't, of course), but it's at least worth |
| 51 |
checking into. I'm using a standard 2.5" HDD like in this[1] so |
| 52 |
perhaps that's why I see the results. |
| 53 |
|
| 54 |
[0] http://www.phoronix.com/scan.php?page=search&q=Btrfs |
| 55 |
[1] http://www.phoronix.com/scan.php?page=article&item=btrfs_old_linux31 |
Archives