4 ms·

I can only speak for myself, but here's the gist of it. (Not an expert in this field so please bear with me if I'm too fuzzy or not rigorous enough). - COW[0]

by K0SM0S 10y ago

I can only speak for myself, but here's the gist of it. (Not an expert in this field so please bear with me if I'm too fuzzy or not rigorous enough). - COW[0] + snapshotting[1] basically give you git-like rollback/failsafe capability. You could e.g. trigger it manually before updating or tweaking stuff, or have it automated everytime you run some pacman/apt/yast/whatever. - subvolumes[2] give you the features of partitioning without the physical/ordering limitations (each subvol can expand into free space, etc.) Combined with snapshots (you can snapshop each subvol discretely as its own fs), especially towards another physical btrfs drive, and some automation tool (like Snapper from openSUSE or simply crons), your 'machine-wide git' becomes an effective backup solution (1st order at least but you can snapshot to several machines including off-site obviously). So it's a "set it up and forget it" very powerful filesystem base for your machine, regardless of what you do with it. Rollback instantly, automated backups, self-healing in case of corruption, and btrfs in single-disk or RAID 0/1/10 is incredibly performant. It basically allows you to utterly destroy your install and get it back up and running within minutes (if your snapshotting strategy is well devised, it can be as painless as a matter of changing the boot drive and fixing a single UUID entry in the /boot files, literally 5 minutes). Note: on your root drive, on OS install you'd typically subvol /home, /var, /var/log (so as to debug externally), or domain folders like /var/www and so on and so forth. It basically makes most 'nix fs architectures constrain-free of most physical drive limitations. [0]: https://btrfs.wiki.kernel.org/index.php/SysadminGuide#Copy_on_Write_.28CoW.29 https://btrfs.wiki.kernel.org/index.php/SysadminGuide#Copy_o... [1]: https://btrfs.wiki.kernel.org/index.php/SysadminGuide#Snapshots https://btrfs.wiki.kernel.org/index.php/SysadminGuide#Snapsh... [2]: https://btrfs.wiki.kernel.org/index.php/SysadminGuide#Subvolumes https://btrfs.wiki.kernel.org/index.php/SysadminGuide#Subvol...

baldfat 10y ago
I ran a btrfs on two production machines and it was more of a headache then a benefit. Now on my server it was a great tool. I could snapshot have an issue then restore to where it was. Desktop has to many file changes and applications from normal uses to be of benefit to me.
- K0SM0S 10y ago
  Agreed you need a bit of pre-thinking going into this. - I don't see much activity on the root volume, most of it in my case is either from VMs or userland. - For VMs I use discrete subvolumes, different fs/snapshot/backup strategies given the intricacies of this use-case. You'd typically snapshot VMs from the hypervisor itself. - /home is its own subvol, with again specific settings. I typically disable COW on /home but adopt a much more agressive snapshot policy (e.g. every hour). Whereas system (/) can COW a lot with little to no performance impact, but snapshot only once a day is usually fine. Note that I only use SSDs (either 2x RAID 0 over SATA 3, or NVMe) and my workstation is a beefy one; so that may explain why I don't see any resource issue whatsoever with these admittedly heavier filesystems (btrfs being much leaner than ZFS in this regard, depending on how you setup the latter). My personal intuition is that major OS suppliers will eventually move to such 'modern' fs under the hood for most users, if only to provide easy rollback/backup features that actually work fine and fast. But it takes years to validate a new fs on an existing architecture, so I wouldn't expect that for Windows or MacOS until the next 'major' version (post-10.x, amusingly in both cases).

by K0SM0S 10y ago

baldfat 10y ago

I ran a btrfs on two production machines and it was more of a headache then a benefit. Now on my server it was a great tool. I could snapshot have an issue then restore to where it was. Desktop has to many file changes and applications from normal uses to be of benefit to me.

K0SM0S 10y ago
Agreed you need a bit of pre-thinking going into this. - I don't see much activity on the root volume, most of it in my case is either from VMs or userland. - For VMs I use discrete subvolumes, different fs/snapshot/backup strategies given the intricacies of this use-case. You'd typically snapshot VMs from the hypervisor itself. - /home is its own subvol, with again specific settings. I typically disable COW on /home but adopt a much more agressive snapshot policy (e.g. every hour). Whereas system (/) can COW a lot with little to no performance impact, but snapshot only once a day is usually fine. Note that I only use SSDs (either 2x RAID 0 over SATA 3, or NVMe) and my workstation is a beefy one; so that may explain why I don't see any resource issue whatsoever with these admittedly heavier filesystems (btrfs being much leaner than ZFS in this regard, depending on how you setup the latter). My personal intuition is that major OS suppliers will eventually move to such 'modern' fs under the hood for most users, if only to provide easy rollback/backup features that actually work fine and fast. But it takes years to validate a new fs on an existing architecture, so I wouldn't expect that for Windows or MacOS until the next 'major' version (post-10.x, amusingly in both cases).