On Tuesday 19 May 2015 08:54:26 Rich Freeman wrote: > On Tue, May 19, 2015 at 6:13 AM, Neil Bothwick <n...@digimed.co.uk> wrote: > > On Tue, 19 May 2015 10:02:38 +0100, Peter Humphrey wrote: > >> > skip mdadm and lvm ... and try btrfs as you have the chance on shiny > >> > new hardware > >> > >> I also have a spare external hard disk, which I could experiment with > >> for snapshots etc. > > > > Snapshots are subvolumes in btrfs, so they stay in the same filesystem. > > That's why they are so fast. > > > > It's a similar situation with ZFS. > > Yup. In both cases they're copy-on-write, so they don't consume > additional space except to the extent that things change. > > Also, in both cases you can serialize a snapshot (either in its > entirety or as a diff vs a previous snapshot) and store it on separate > storage. This is mainly done for backup (storing the serialized > files) or replication (replaying them onto another server with the > same filesystem). > > But, neither ZFS nor btrfs are without issue on Linux, so I'd use care > in a production environment. The btrfs issues tend to revolve around > stability, and the zfs issues tend to revolve around dealing with > out-of-mainline code and legal/license issues.
Well, this is my toy desktop, so no risk to fame and fortune there. By /toy/, of course, I mean I play with it, not that it's a Mickey-Mouse setup (which some of you pros out there might think it is anyway, but that's another story). Some people will remember that I had a fling with f2fs on my little Atom LAN server some months ago; I don't think I'll be using that this time! Incidentally, what's the received wisdom on frequency of file-system trimming on SSDs these days? I've seen values quoted between twice a day and once a week. And how does trimming affect btrfs? Hmm. Looks like I'm hijacking Nuno's thread. Apologies if that's ruffled any feathers, but I think I'm still on-topic, more or less, and he may still be interested in the conversation. - Rgds Peter
