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