Re: [Nbd] Question about the expected behaviour of nbd-server for async ops
- To: Alex Bligh <alex@...872...>
- Cc: nbd-general@lists.sourceforge.net, Wouter Verhelst <w@...112...>
- Subject: Re: [Nbd] Question about the expected behaviour of nbd-server for async ops
- From: Goswin von Brederlow <goswin-v-b@...186...>
- Date: Mon, 30 May 2011 11:29:54 +0200
- Message-id: <874o4ca63x.fsf@...860...>
- In-reply-to: <8F9E38C3D28607590CFC023D@...873...> (Alex Bligh's message of "Sun, 29 May 2011 19:27:16 +0100")
- References: <87oc2m28o7.fsf@...860...> <6DBA2A6208847F844397DB62@...873...> <87wrh9bz0c.fsf@...860...> <0F0AB0F66B196FBBE86999A5@...874...> <87fwnxy8gi.fsf@...860...> <20110529175435.GG31747@...510...> <8F9E38C3D28607590CFC023D@...873...>
Alex Bligh <alex@...872...> writes:
> --On 29 May 2011 19:54:35 +0200 Wouter Verhelst <w@...112...> wrote:
>
>>> Which just means that a CoW based filing system or sparse files don't
>>> support FUA. The idea of a FUA is that it is cheaper than a FLUSH. But
>>> if nbd-server does fsync() in both cases then it is pointless to
>>> announce FUA support.
>>
>> No, that's not entirely true. With a FLUSH, you need to ensure that
>> whatever the FLUSH would cover is flushed to disk; with a FUA, you need
>> to ensure the same thing for just one call, which is easier to do.
>
> Indeed. And even if we were limited to fsync() by something other than
> my laziness, then we'd still only need to fsync() one file, rather than
> every file (in a device spanning multiple files).
Ahh, I forgot about multiple files. Ok, so FUA will be cheaper in that
case even if it still does more than it needs too.
MfG
Goswin
Reply to: