Alternatives to the Cloud

[GreyGeek]

A lot of OLD claims about Btrfs being "experimental" and "unstable" are floating around. The Btrfs Status page is here. On it one will note that only the RAID56 code is unstable. The rest is either "mostly OK" or "OK".

Performance
Trim (aka. discard)	OK	fstrim and mounted with -o discard (has performance implications)
Autodefrag	OK
Defrag	mostly OK	extents get unshared (see below)
Compression & deduplication
Compression	mostly OK	(needs verification and source) auto-repair and compression may crash
Out-of-band dedupe	mostly OK	performance issues
File range cloning	mostly OK	(reflink), heavily referenced extents have a noticeable performance hit
Reliabillity
Auto-repair	OK	automatically repair from a correct spare copy if possible (dup, raid1, raid10)
Scrub	OK
Scrub + RAID56	Unstable	will verify but not repair
nodatacow	OK	(see below)
Device replace	mostly OK	gets stuck on devices with bad sectors
Balance	OK
Block group profile
Single (block group profile)	OK
DUP (block group profile)	OK
RAID0	OK
RAID1	mostly OK	Needs at least two available devices always. Can get stuck in irreversible read-only mode if only one device is present.[1] [2]
RAID10	mostly OK	Needs to be able to create two copies always. Can get stuck in irreversible read-only mode if only one copy can be made.[3] [4]
RAID56	Unstable	write hole still exists, parity not checksummed
Mixed block groups	OK	see documentation
Administration
Filesystem resize	OK	shrink, grow
Offline UUID change	OK
Subvolumes, snapshots	OK
Send	OK	corner cases may still exist
Receive	OK
Seeding	OK	should be better documented
Quotas, qgroups	mostly OK
Misc
Free space tree	mostly OK	see below
no-holes	OK	see documentation for compatibility
skinny-metadata	OK	see documentation for compatibility
extended-refs	OK	see documentation for compatibility

[GreyGeek]

I have used Btrfs for only two & 1/2 years. I have never had a problem with it. I am currently running a RAID1 on two 750 Gb HDs and back up snapshots to another 750GB HD mounted at /backup. When I was running VirtualBox I marked the folder that the virtual drives were going into as nocow, and I touched new virtual drives and set them as nocow before I created them in VirtualBox. I also made my virtual HDs static (fixed size) not dynamic. Taking those precautions I never had a problem with Btrfs & VirtualBox co-existing. Up until a couple weeks ago I was running a PostgreSQL server and it never gave me any problem with Btrfs either.

I was looking into writing my own GUI for Btrfs but when I analyzed my usecase it became obvious to me that a GUI would not make my backup or recovery work any easier than doing the work manually as root, as I documented in another thread. I can put those commands in a script which prompts for the root password and creates an automatic date extension for the ro snapshots, but the snapshots are created in milliseconds and doing an up arrow to get the first command, arrowing over and adding "home" behind "@", hitting the "End" key and pressing return is about just as fast. When doing a send & receive the @bkup send takes about 10-15 minutes and the @homebkup send takes about twice as long. I can't say how long a restore would take because in 2 1/2 yrs, since moving to NEON, I've never had to do one.

[steve7233]

Be not the first by whom the new are tried,
Nor yet the last to lay the old aside.Alexander Pope, An Essay on Criticism, 1711
English poet & satirist (1688 - 1744)

Sounds like how TV networks and movie companies think.