1 |
Am 14.08.2012 19:21, schrieb Jason Weisberger: |
2 |
> Sure, but wouldn't compression make write operations slower? And isn't he |
3 |
> looking for performance? |
4 |
> On Aug 14, 2012 1:14 PM, "Pandu Poluan" <pandu@××××××.info> wrote: |
5 |
> |
6 |
>> |
7 |
>> On Aug 14, 2012 11:42 PM, "Helmut Jarausch" <jarausch@××××××××××××××××.de> |
8 |
>> wrote: |
9 |
>>> |
10 |
>>> On 08/14/2012 04:07:39 AM, Adam Carter wrote: |
11 |
>>>> |
12 |
>>>>> I think btrfs probably is meant to provide a lot of the modern |
13 |
>>>>> features like reiser4 or xfs |
14 |
>>>> |
15 |
>>>> Unfortunately btrfs is still generally slower than ext4 for example. |
16 |
>>>> Checkout http://openbenchmarking.org/, eg |
17 |
>>>> http://openbenchmarking.org/s/ext4%20btrfs |
18 |
>>>> |
19 |
>>>> The OS will use any spare RAM for disk caching, so if there's not much |
20 |
>>>> else running on that box, most of your content will be served from |
21 |
>>>> RAM. It may be that whatever fs you choose wont make that much of a |
22 |
>>>> difference anyways. |
23 |
>>>> |
24 |
>>> |
25 |
>>> If one can run a recent kernel (3.5.x) btrfs seems quite stable (It's |
26 |
>> used by some distribution and Oracle for real work) |
27 |
>>> Most benchmark don't use compression since other FS can't use it. But |
28 |
>> that's unfair. With compression, one needs to read |
29 |
>>> much less data (my /usr partition has less than 50% of an ext4 |
30 |
>> partition, savings with the root partition are even higher). |
31 |
>>> |
32 |
>>> I'm using the mount options |
33 |
>> compress=lzo,noacl,noatime,autodefrag,space_cache which require a recent |
34 |
>> kernel. |
35 |
>>> |
36 |
>>> I'd give it a try. |
37 |
>>> |
38 |
>>> Helmut. |
39 |
>>> |
40 |
>> |
41 |
>> Are the support tools for btrfs (fsck, defrag, etc.) already complete? |
42 |
>> |
43 |
>> If so, I certainly would like to take it out for a spin... |
44 |
>> |
45 |
>> Rgds, |
46 |
>> |
47 |
>> |
48 |
> |
49 |
|
50 |
I have enough cpu power at hand for compression, I guess that should not |
51 |
be the issue. But the cache dir mostly consists of prescaled jpeg |
52 |
images, so compressing them again would not give me any benefits, speed- |
53 |
or size-wise. |