On 10/11/22 10:50, Carlos E. R. wrote:
On 2022-10-11 08:54, Robert Webb wrote:
On Mon, 10 Oct 2022 21:16:23 -0700, Lew Wolfgang <wolfgang@sweet-haven.com> wrote:
On 10/10/22 19:39, Robert Webb wrote:
[...] [1] https://github.com/trapexit/mergerfs
Thanks for the pointer, Robert! I've never used anything like this, but I did dabble with zfs once.
Does mergerfs allow each of the drives in a pool to be mounted individually on another host? That's one of our requirements, that the drives not be aggregated or raided together. Our requirement isn't for archiving, but for data dissemination to possibly non-Linux systems not administrated by us.
Yes, according to the README.md on the linked page (That's all the info I have. I have never used it), all the disks/filesystems can be used independently, without mergerfs. If one of the disks fails, it only affects the files on that one drive. There is no extra error correction. The filesystems aren't even required to be the same: "Works with heterogeneous filesystem types".
When you do use multiple drives together under mergerfs, its ability to use a changed configuration at runtime might be useful to control which drive has priority to get written to.
Can you connect all the destination disks at once, and issue a single copy command to write all the files? And the files not being split.
That would be the goal.
The set of destination disks could be connected simultaneously if done using USB3.
We can connect five SATA disks simultaneously in a 2U chassis. The other 19 disks are part of a RAID6 array.
The advantage would be not needing to be there to change the disks; just issue a single command and have the copy process run for hours or days, undisturbed.
But even the five disks might fill up, so changing will probably be required. Regards, Lew