Eskating cyclist, gamer and enjoyer of anime. Probably an artist. Also I code sometimes, pretty much just to mod titanfall 2 tho.
Introverted, yet I enjoy discussion to a fault.
fsync isn’t part of wine, which is what they are referring to.
Fsync and Esync are both inaccurate representations and help in some places, while breakingnother things. Hence, while useful for games, they never got mainlined.
NTsync is an accurate reimplementation, hence why this functionality will finally become part of wine proper.
then what’s the advantage of using that over the native capabilities of btrfs?
btrfs multi device file systems have some limitations. Adding a drive is instant, but if you want to stripe the data using raid0, that requires a lengthy balancing operation. The alternative is “single” mode, which does not concern itself with striping, and just pools the storage available. The disadvantage, is that in single mode you get the risk of raid0, with no performance benefit. btrfs does not actually make sure that the different blocks that constitute a single file end up on the same drive, which means that if one fails, you still likely lose everything.
MergerFS does not mess with any of the filesystems being combined. It can be configured to work in different ways, but each drive will remain its own, consistent, functioning file system. Drives can be browsed individually, removed, added etc. Instantly. To “empty” a drive, you just move the files on it to the rest by using the non merged folders. By default, “writing” a new file will always go to the drive with the most free space, and individual files cannot be stored “across” several drives even though the contents of a folder can be. This way, whatever is on each drive, can never be damaged by the failure of another drive.
So the benefits are isolation, and convenience. The downside is a definite performance hit, which may not be significant depending on your system or what you’re storing in the merged filesystem.
So I could do that for the root folder as well I imagine?
No. And you wouldn’t want to. First for the performance hit. Second, because mergerfs merges folders (drives have to be mounted, first), and uses a third as a mountpoint. As an example, to “expand” your home folder, you’d move your homefolder somewhere else, then merge that moved folder with the new drive (which you still have to mount somewhere), and then you’d mount the resulting file system where your old home folder was before.
You could even have two folders on the second drive. Use one to merge somewhere you want to pool all your storage, and the other to put stuff on the second drive in a way where losing the first won’t make half the files go missing. You might use that to store a copy of the OS install from the first drive, for example.
If you want to just extend storage space, maybe mergerfs?
/media is now for the system to mount stuff automatically. Using /mnt for something you’re confusing personally is fine.
Yup. And it’ll be a huge improvement overall to simply have both performance and accuracy in one, and not have to pick one or the other, regardless of what application is being run.