Folkert, --On 13 September 2011 13:49:48 +0200 [email protected] 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 ------------------------------------------------------------------------------ BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA Learn about the latest advances in developing for the BlackBerry® mobile platform with sessions, labs & more. See new tools and technologies. Register for BlackBerry® DevCon today! http://p.sf.net/sfu/rim-devcon-copy1 _______________________________________________ Nbd-general mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/nbd-general
