On 2018-12-13 05:39, Remi Gauvin wrote:
On 2018-12-13 02:29 AM, Adam Borowski wrote:
For btrfs, a block device is a block device, it's not "racist".
You can freely mix and/or replace. If you want to, say, extend a SD
card with NBD to remote spinning rust, it works well -- tested :p
The possibility ff NBD certainly intrigues me, but I would be concerned
about the write barriers,, (needed to make sure cached writes are
committed to spinning rust in the correct order, so as to avoid
corruption in the case of interruption.
Assuming the underlaying block device on the remote device has a working
implementation, (as we know, not always a safe assumption...) does NBD
properly pass along the barriers commands/support?
I don't think there's any auto-detection, but newer versions of the NBD
server software provide two options in the export configuration,
`flush`, and `fua`, which will let you enable support for those two
commands, though they only get used if the client supports them.
Unless I'm mistaken, they both need support from the block device being
exported if it's actually a block device, though they do not if it's a
regular file (`flush` translates to `fdatasync()` or `fsync()`, while
`fua` translates to `sync_file_range()`).
