On 2017-02-01 00:09, Duncan wrote:
Christian Lupien posted on Tue, 31 Jan 2017 18:32:58 -0500 as excerpted:
I have been testing btrfs send/receive. I like it.
During those tests I discovered that it is possible to access and modify
(add files, delete files ...) of the new receive snapshot during the
transfer. After the transfer it becomes readonly but it could already
have been modified.
So you can end up with a source and a destination which are not the
same. Therefore during a subsequent incremental transfers I can get
receive to crash (trying to unlink a file that is not in the parent but
should).
Is this behavior by design or will it be prevented in the future?
I can of course just not modify the subvolume during receive but is
there a way to make sure no user/program modifies it?
I'm just a btrfs-using list regular not a dev, but AFAIK, the behavior is
likely to be by design and difficult to change, because the send stream
is simply a stream of userspace-context commands for receive to act upon,
and any other suitably privileged userspace program could run the same
commands. (If your btrfs-progs is new enough receive even has a dump
option, that prints the metadata operations in human readable form, one
operation per line.)
So making the receive snapshot read-only during the transfer would
prevent receive itself working.
That's correct. Fixing this completely would require implementing
receive on the kernel side, which is not a practical option for multiple
reasons.
That said, some improvements could be made, such as making everything
0700 and owned by the user running receive initially, then updating the
metadata at the end of the operation.
There are also a handful of other security concerns with send/receive
(the most notable being that receive doesn't validate the send stream
against the receiving system as well as it should), so I would generally
recommend not using send/receive outside of a tightly controlled
environment.
I can also get in the same kind of trouble by modifying a parent (after
changing its property temporarily to ro=false). send/receive is checking
that the same parent uuid is available on both sides but not that
generation has not changed. Of course in this case it requires direct
user intervention. Never changing the ro property of subvolumes would
prevent the problem.
Again is this by design?
Again, yes. The ability to toggle snapshots between ro/rw is a useful
feature and was added deliberately. This one would seem to me to be much
like the (no doubt apocryphal) guy who went to the doctor complaining
that when he beat his head against the wall, it hurt. The doctor said,
"Stop doing that then."
Agreed, especially considering that some of the most interesting
use-cases for send/receive (which requires the sent subvolume to be
read-only) require the subvolume to be made writable again on the other end.
Otherwise I would suggest finding a way to avoid those conditions (using
the generation maybe?). There could be an override option to allow more
flexibility if needed.
There's a send-stream format version bump planned, that should fix
various issues and eliminate various limitations. However, in ordered to
minimize the number of format versions that must continue to be supported
into the future, they don't plan to do that bump until they're relatively
sure their list of changes to make is complete. They don't want to do
the bump and then a kernel series or two later discover they need yet
another tweak.
Remember, btrfs' status remains "stabilizing, but not yet fully stable
and mature." A lot of stuff hasn't been optimized either, because
they're focused on eliminating the bugs and adding missing features
still, not optimizing, at this point, and they don't want to spend a
bunch of time optimizing something, only to have to rewrite or even just
tweak it, perhaps to support say N-way-mirroring, and have to redo the
optimization as a result.
This sort of additional sync guarantees may be in the final generally
considered stabilized product, but that's yet some time (years) away.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
