1 |
On Mon, Dec 29, 2014 at 8:55 AM, lee <lee@××××××××.de> wrote: |
2 |
> |
3 |
> Just why can't you? ZFS apparently can do such things --- yet what's |
4 |
> the difference in performance of ZFS compared to hardware raid? |
5 |
> Software raid with MD makes for quite a slowdown. |
6 |
> |
7 |
|
8 |
Well, there is certainly no reason that you couldn't serialize a |
9 |
logical volume as far as design goes. It just isn't implemented (as |
10 |
far as I'm aware), though you certainly can just dd the contents of a |
11 |
logical volume. |
12 |
|
13 |
ZFS performs far better in such situations because you're usually just |
14 |
snapshotting and not copying data at all (though ZFS DOES support |
15 |
serialization which of course requires copying data, though it can be |
16 |
done very efficiently if you're snapshotting since the filesystem can |
17 |
detect changes without having to read everything). Incidentally, |
18 |
other than lacking maturity btrfs has the same capabilities. |
19 |
|
20 |
The reason ZFS (and btrfs) are able to perform better is that they |
21 |
dictate the filesystem, volume management, and RAID layers. md has to |
22 |
support arbitrary data being stored on top of it - it is just a big |
23 |
block device which is just a gigantic array. ZFS actually knows what |
24 |
is in all those blocks, and it doesn't need to copy data that it knows |
25 |
hasn't changed, protect blocks when it knows they don't contain data, |
26 |
and so on. You could probably improve on mdadm by implementing |
27 |
additional TRIM-like capabilities for it so that filesystems could |
28 |
inform it better about the state of blocks, which of course would have |
29 |
to be supported by the filesystem. However, I doubt it will ever work |
30 |
as well as something like ZFS where all this stuff is baked into every |
31 |
level of the design. |
32 |
|
33 |
-- |
34 |
Rich |