NOOB general questions

[KutX9JtmXrZP]

Noob user here with a bunch of questions if you don't mind - wanna be sure I've got it correct in my head before I dive in...So this is more conceptual than code literal.

First - Dude your documentation ROCKS! You have put major effort into it and it helped a ton. Thank you.

Second - Your note about making drive labels the same as the serial number - brilliant. Don't know why I've never thought of it.

Ok, now the questions - in all cases the drives are either direct attached to the MB (sata/nvme) or in a USB Enclosure. All will be LUKS encrypted.

Ultimately what I want to do is create a pool for my SSDs and a separate pool for my mechanical HDDs. I really just don't want to care what drive something goes on anymore. Especially since I often wind up with 1 drive 90% full and the others mostly empty.

The usb enclosure is going to have all spinning rust and be my weekly "backup" drive (4 data disks, 2 parity for snapraid). This way I can grab it and go when there's a wildfire coming my way (it happens where I live).

1. Use case:

Virtual Machines - On my system I like using virtual machines for different tasks - One VM for social media, another for web development, one for banking, some games (freedos & WinXP mostly), etc. with the datafiles I'm working on (for example the website files themselves) outside the vm

Databases are also lightweight...LibreOffice Base mostly, some MySQL or MariaDB for dev work (wordpress installed in a vm kinda thing). Calibre to manage my ebooks

From the ReadMe, I get the impression that the main reason to avoid mixing mergerfs with VMs and Databases generally is a performance hit resulting from the overhead; if I'm reading it correctly. But other than that it should work. Am I right? And if the performance is crap then go direct to the drive - basically what I'm doing now...

So it would be a "test and see" kinda thing rather than a technical "don't do it or you'll rip a hole in spacetime" kinda thing.

2. Setting up

Regardless of where (fstab, cli) you setup mergerfs you're referring back to the mountpoints - not the location (/sda/sda1) or device (/dev/sda). Which means that the drives must be mounted first (and unlocked/mapped) and remain so. Should be obvious, but I'm still on my first cup of coffee.

-- mmap: Again it looks like this is a "test and see" kinda thing. What should we look for if we don't know for sure if we need to worry about it? The docs all point to this affecting caching - so it's a speed thing?

I think that's it for now. Thanks

[trapexit]

1. Correct. Just need to account for mmap vs regular io. For example: sqlite3 using software often force mmap for some reason and if you use direct io mode (cache.files=off) then that can fail. If/when I add passthrough to mergerfs then this usecase will be less of a concern.
2. If the path exists when mergerfs starts it won't care. Once the mount occurs you're fine. mergerfs isn't currently opening the root of the branch on startup.
3. Generally enabling page caching in FUSE negatively affects performance. It's something the community has needed to look into but just hasn't happened. But page caching is required for shared mmap to work. The only way to know if you need it is to test your apps. A lot of software that use sqlite3 set it up to use mmap thinking it will be faster but that isn't necessarily true and they often just fail rather than fall back to regular IO. IMO that should be a bug report on that software but 🤷‍♂️ .

[KutX9JtmXrZP]

Thanks. And for VM/Database stuff it's test and see, right?

[trapexit]

Yes, under the conditions as I mentioned above which ultimately apply to every app.

[KutX9JtmXrZP]

Thank you again. I look forward to playing :D