| 1 |
On Tue, May 19, 2015 at 6:13 AM, Neil Bothwick <neil@××××××××××.uk> wrote: |
| 2 |
> On Tue, 19 May 2015 10:02:38 +0100, Peter Humphrey wrote: |
| 3 |
> |
| 4 |
>> > skip mdadm and lvm ... and try btrfs as you have the chance on shiny |
| 5 |
>> > new hardware |
| 6 |
>> |
| 7 |
>> I also have a spare external hard disk, which I could experiment with |
| 8 |
>> for snapshots etc. |
| 9 |
> |
| 10 |
> Snapshots are subvolumes in btrfs, so they stay in the same filesystem. |
| 11 |
> That's why they are so fast. |
| 12 |
> |
| 13 |
> It's a similar situation with ZFS. |
| 14 |
|
| 15 |
Yup. In both cases they're copy-on-write, so they don't consume |
| 16 |
additional space except to the extent that things change. |
| 17 |
|
| 18 |
Also, in both cases you can serialize a snapshot (either in its |
| 19 |
entirety or as a diff vs a previous snapshot) and store it on separate |
| 20 |
storage. This is mainly done for backup (storing the serialized |
| 21 |
files) or replication (replaying them onto another server with the |
| 22 |
same filesystem). |
| 23 |
|
| 24 |
But, neither ZFS nor btrfs are without issue on Linux, so I'd use care |
| 25 |
in a production environment. The btrfs issues tend to revolve around |
| 26 |
stability, and the zfs issues tend to revolve around dealing with |
| 27 |
out-of-mainline code and legal/license issues. |
| 28 |
|
| 29 |
-- |
| 30 |
Rich |
Archives