Could LTFS be a valid send/receive target?

[Arya-Elfren]

I don't know what the current send/receive plans are, but would the format work with an ltfs (as in tape) target? If I want to transfer a lot of data between two locations without carrying hard drives or even where both systems are live I could then do (pseudo) bcachefs send > tape, carry the tape (or even tapes?) over, and bcachefs receive < tape.

[Arya-Elfren]

Two potential additions:

1. (Partial) incremental support without live access to the other end. "Partial" because you almost certainly can remove more redundancy with a live connection to the other end. My naive idea for this would be the ability to specify one/many snapshots that are known to exist on the other end. i.e. bcachefs send --last-snap=foo
2. Encryption/compression? This is a (?) because it might be preferred to just bcachefs send | compress | encrypt (and encryption is transparent in the "send over network" case already), however, having the settings in-band makes it much easier. It might make sense to use existing compression settings to reduce workload (decompress+recompress) or pointless compression (compressing already compressed data). But if it were for storage or moving to a lower power machine I would appreciate being able to enforce/recompress to a higher ratio on send.

---

This should probably be its own issue, I have doubts about it's reasonableness and just want to confirm that it's a bad idea: subvolume/snapshot level encryption (at least in a restricted case?). Not necessarily that every user could encrypt their home subvolume (which would be cool but probably breaks a lot of things and the threat model handled wouldn't be very strong...) but that I could bcachefs send to an untrusted server and later bcachefs receive from that server to restore from backup.

This is probably more reasonably solved by doing the above send to a file, encrypt+upload the file, and then download+decrypt+receive from the file locally.