Storage target mode is block-level, not filesystem-level, meaning it won't support concurrent access and any network hiccup or dropped connection will leave the filesystem in an unclean state.
> ...any network hiccup or dropped connection will leave the filesystem in an unclean state.
Given that the docs claim that this is an implementation of an official NVMe thing, I'd be very surprised if it had absolutely no facility for recovering from intermittent network failure. "The network is unreliable" [0] is axiom #1 for anyone who's building something that needs to go over a network.
If what you report is true, then is the suckage because of SystemD's poor implementation, or because the thing it's implementing is totally defective?
[0] Yes, datacenter (and even home) networks can be very reliable. They cannot be 100% reliable and -in my professional experience- are substantially less than 100% reliable. "Your disks get turbofucked if the network ever so much as burps" is unacceptable for something you expect people to actually use for real.
NVME only provides block IO. An interruption of the connection is equivalent to forcibly unplugging a hard drive. If the filesystem you put on top supports that and is able to recover from that, you're fine. But most filesystems do not optimize for that happening anywhere near as frequently as it would if you were using this as a regular file sharing protocol over unreliable networks.
Sure. NVMe provides block IO carried over a variety of transports. The one we're talking about is TCP.
> An interruption of the connection is equivalent to forcibly unplugging a hard drive.
Remember that I said in my footnote:
"Your disks get turbofucked if the network ever so much as burps" is unacceptable for something you expect people to actually use for real.
A glance at the spec reveals that TCP was chosen to provide reliable, in-order transmission of NVMe payloads. TCP is quite able to recover from intermittent transport errors. You might consider reading the first paragraph of sections 2 and 3.3, as well as sections 3.4, 3.5, and the first handful of paragraphs of section 3.5.1 of the relevant spec. [0]
If you're truly seeing disk corruption whenever the network so much as burps, then it sounds like the SystemD guys fucked something up.
