Re: [Nbd] fua, trim, etc
Folkert,
--On 13 September 2011 13:49:48 +0200 folkert.van.heusden@...17... wrote:
In my opinion fua should at least stay connected to the mount "barrier"
Flag. Especially when the nbd-server aggressively reorders writes this is
a useful flag to know what must go to disk first. E.g. servers with a
delayed write cache like my pet project (data de-duplicator).
Maybe default do what kernel tells you and user can override this to
ignore when he only cares about performance.
The mount command will still be connected, in that controls whether
the FS will issue such commands. However, you can't use just that, because
the device connect happens first. For instance, if the nbd device
is connected to a VM, the VM running the FS which will eventually
mount won't even have started.
When barriers are turned off, you thus will never get FUA/FLUSH sent.
You don't want to ALWAYS send them, because the server may not support
them (and you might want to turn them off on the server, e.g. to
stop 3rd party VM clients being 'expensive' to service).
I agree that sending FUA/FLUSH when the server advertises that
availability is probably always sensible - which in practice
means it is controlled by the mount command/fs in that they
won't be generated unless the fs wants them.
--
Alex Bligh
Reply to: