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.
Sent from my HTC ----- Reply message ----- From: "Alex Bligh" <[email protected]> To: "Paolo Bonzini" <[email protected]> Cc: "Wouter Verhelst" <[email protected]>, "Folkert van Heusden" <[email protected]>, <[email protected]>, "Alex Bligh" <[email protected]> Subject: [Nbd] fua, trim, etc Date: Tue, Sep 13, 2011 13:25 Paolo, --On 13 September 2011 13:14:01 +0200 Paolo Bonzini <[email protected]> wrote: > On 09/13/2011 12:49 PM, Alex Bligh wrote: >> For instance, Paul's suggestion on setting 'rotational' using /proc >> instead is definitely better than the way nbd-client does it at the >> moment. > > That can go in later, right? Well, it's in at the moment. I'd rather not remove that functionality. But yes, the change of mechanism can go in later. >>> - Make NBD_CMD_TRIM cause nbd-server to call fallocate() with >>> FALLOC_FL_PUNCH_HOLE. >> >> We need to be a bit careful on these. IIRC (someone please check!) >> on Linux fallocate() is an extended call that supports various stuff, >> whereas posix_fallocate() is the normal POSIX call, and that doesn't >> support PUNCH_HOLE. On non-Linux systems, fallocate() is the normal >> POSIX call. > > No, it's really called posix_fallocate elsewhere. Non-Linux system might > alias fallocate and posix_fallocate, but the name in POSIX is really > posix_fallocate. My mistake. > However, flush/fua should likely _not_ be opt-in, because they are > required for safety. Personally I would agree with you. However, there were wars between distros as to whether ext3 should use FLUSH and FUA by default, and ext2 never used them. There are actually subtly different questions here: 1. Should the server advertise flush and fua support by default (the answer here is pretty obviously yes in my book - though currently it doesn't). 2. Should the client send flush and fua by default if the server advertises it (I think the answer is yes here too, though currently it doesn't). Note, when considering defaults, that FUA is not as efficient as it might be, because in essence it does a flush(). Better would be to have a completely separate file opened with O_SYNC (see archives). I think we should at least measure the performance implications before we change the defaults. -- 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
