It depends on the usage. It isn’t necessarily better, it’s different.
That said, as stated previously, there are many things BTRFS is better at, whether you use those features is up to you.
Because that’s the way the Rockstor software has been designed. It only understands how to manage BTRFS disks. Not using BTRFS breaks it’s way of handling things. You can probably coax some functionality out of it, but why bother for something that works well anyway?
I don’t understand why you would think this. My primary is a 2.5" SATA SSD, working fine since install, ~1.5 years ago.
You’re correct in that EXT2 has no journalling, and this does potentially reduce the life of an SSD a bit. I think you’d have trouble measuring the lifespan difference though, especially as (by your statement) it shouldn’t be written to very much anyway, meaning the journal will also remain largely untouched.
It is needed, because the software has been designed around it.
The short answer here is that it’s a shorter development cycle to only support limited configurations.
Allowing for filesystems other than BTRFS means writing interface and management code for different sets of tools, and modularizing the disk management system to allow for it.
This means longer between releases, more things that can break and more code overhead to manage for a very small team of developers.
Speak for yourself. I have my Rockon root on the system drive, and would be quite upset if I couldn’t snapshot it.
I’m also using BTRFS replication to mirror the system disk offsite in case something blows up.
Metadata is on the disk as well, but storage of small files inside the metadata is more space and seek efficient than storing on the filesystem itself. This can keep things very speedy for groups of small files (such as the contents of “/run”
The advantage here is that to store a file, you need to allocate a whole filesystem block (or BTRFS extent) for it. If that block is larger than the file you’ve stuck in it, you have a chunk of wasted space.
If your EXT2 block is 4K and you have a large amount of 512 byte files, you’re using 8x the amount of space required for your files.
BTRFS can store these in the smaller metadata blocks, meaning less space wastage. The internal btree algo can also pack multiple small files into a single metadata block, further saving space.
Actually, BTRFS can grow/shrink a filesystem in use by the OS, as well as add/remove disks.
This is fantastic if your limited lifespan SSD starts showing signs of failure, you can add a new disk to the pool as a RAID1, pull the other disk out, and perform a btrfs device delete missing
And databases, updates, system state management files, FIFO sockets…
This is a very opinionated statement from a very narrow point of view.
There are many reasons (some of which I’ve already outlined for you) that BTRFS can be useful on the primary disk. Again, whether you use them or not is your own choice, but that doesn’t make them not valid reasons.
Also, a perfectly good reason for having BTRFS on the main drive is because that’s how the software is designed. When you’re building the software yourself, you can make all sorts of design decisions, like the Rockstor team has.
Reflinks are a fantastic idea. I look forward to the day Rockstor and other software starts using them efficiently.
These allow you to copy an existing file as a reflink to the original. The copy can be modified without altering the original (such as what you get with soft/hard links), and instead of two whole copies of the file, the only space used is the space required to store the changes.
It’s based on the same concept (CoW) BTRFS uses for it’s snapshots.
[EDIT] Deleted some argumentative crap, didn’t need to be there.