Using composable tools is also better from a maintenance standpoint. If tomorrow SnapRAID stops working, I can replace just that component with something else without affecting the rest of the system.
Using composable tools is also better from a maintenance standpoint. If tomorrow SnapRAID stops working, I can replace just that component with something else without affecting the rest of the system.
Can you actually? If some layer of that storage stack stops working then you can no longer access your existing data, because all these layers need to work correctly to correctly reassemble the data read from disk.
Did you miss the part where I mentioned "for personal use"?
> Since all those tools are from different dev's the system gets more complex.
I fail to see the connection there. Whether software is developed by a single entity or multiple developers has no relation to how complex the end user system will be.
But many small tools focused on just the functionality I need allows me to build a simpler system overall.
The first part of this sentence is probably true, as far as I see, but the complexity of a system perceived by the user depends primarily on the "surface" of the system. That surface includes the UI, the documentation and important concepts you have to understand for effective usage of the system. And in that regard, ZFS wins hands down against LUKS + LVM + SnapRaid + your FS of choice. Some questions a user of that LVM stack has to answer, aren't even asked of a ZFS user. E.g. the question how to split the space between volumes or how to change the size of volumes.
Since ZFS is simpler to use then your setup, is used to store 55PB of data without a single bit error since 2012, i don't see why someone should use inferior stuff, even when it's "personal use".
>But many small tools focused on just the functionality I need allows me to build a simpler system overall.
Sometimes monoliths are better for example the network-stack and storage....maybe kernels (big Maybe here)