1 |
Boyd Stephen Smith Jr. wrote: |
2 |
>> <troll> |
3 |
>> ZFS? |
4 |
>> </troll> |
5 |
> |
6 |
> You say troll, I say possibility; I'll certainly consider it. |
7 |
|
8 |
Actually, I would be very interested in using ZFS for my data. |
9 |
|
10 |
The "troll" was more about the fact that the ZFS license was explicitly |
11 |
designed to be GPL-2 incompatible, hence preventing it from being |
12 |
included into Linux (it would require a clean-room rewrite from the specs). |
13 |
|
14 |
> However, the demos that I've seen about ZFS stress how easy it is to |
15 |
> administer, and all the LVM-style features it has. Personally, |
16 |
> I've /very/ comfortable with LVM and am of the opinion that such features |
17 |
> don't actually belong at the "filesystem" layer. |
18 |
|
19 |
I haven't made the step to LVM and am still using a plain old RAID-1 |
20 |
mirror. I'm not that comfortable adding one more layer to the data path, |
21 |
and one more difficulty in case of hard disk failure. |
22 |
|
23 |
> I need to good general purpose filesystem, what matters most to be is: |
24 |
> 1) Online growing of the filesystem, with LVM I use this a lot, I won't |
25 |
> consider a filesystem I can't grow while it is in active use. |
26 |
> 2) Journaling or other techniques (FFS from the *BSD world does something |
27 |
> they don't like to call journaling) that reduce the frequency of full |
28 |
> fscks. |
29 |
> 3) All-round performance, and I don't mind it using extra CPU time or |
30 |
> memory to make filesystem performance better, I have both to spare. |
31 |
> 4) Storage savings (like tail packing or transparent compression) |
32 |
|
33 |
I completely agree with 1) and 2), and 3) and 4) are nice to haves. What |
34 |
I like in ZFS is the data integrity check, i.e. every block gets a |
35 |
checksum, and it can auto-repair in a RAID-Z configuration, something |
36 |
that RAID-1 cannot. |
37 |
|
38 |
So I would add: |
39 |
5) Reliable data integrity checks and self-healing capability. |
40 |
|
41 |
-- Remy |