Re: [Nbd] fua, trim, etc

[Alex Bligh <alex@...872...>]

Paolo,

--On 13 September 2011 13:14:01 +0200 Paolo Bonzini <pbonzini@...696...> 
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