Illegal Seek on Local-Only Union

I am using rclone's union backend to pool the storage of multiple local disks in a way that retains complete files on singular disk failures. I realized, that without a vfs-cache-mode of writes or higher, non-sequential writes to the mounted backend would return a seek error.

Now this behaviour is well-documented and with the significant amount of different backends (including some which cannot handle non-sequential writes at all) supported, it makes total sense for me why it works this way. But with my current situation of the union backend only consisting of local upstreams, I would guess that at least the technical possibility of supporting non-sequential writes without any VFS caching would exist.

Is customizing the union backend logic to support non-sequential mount writes directly as long as the relevant upstream backend does so, at all in the cards? Or is the consistency across backends and rigorousness of the abstraction too important for this to be a good idea?

rclone from the start was build to operate on object/cloud storages. Would it be possible to create some exceptional behaviour for this edge case? Like usually with software answer is yes but not sure if it makes sense.

In your case I would suggest you use right tool for the job. Look at mergerfs which only focus is local filesystems. BTW rclone union borrowed quite few ideas from this project so you should be immediately familiar how to use it.

I know about mergerfs, but I have only recently switched over to a completely local setup and wanted to keep using rclone for it's flexibility and the option of layering other stuff on top in the future (e.g. caching, encryption, etc.). Having to use a VFS cache is just a little odd, but not actually a big issue and my use case doesn't require the additional performance that using mergerfs would likely bring to the table.

But you're right, barring significant interest from a number of people, it makes sense that such a specific improvement outside rclone's primary functionality makes little sense. Thank you for the answer and the additional information.

I'll just add that this is a good idea, but I haven't had enough bandwidth to implement it!