Alex Bligh <[email protected]> writes:
> --On 29 May 2011 12:42:01 +0200 Goswin von Brederlow
> <[email protected]> wrote:
>
>> This would not scale well with many flush requests in parallel but I
>> hope it is save to assume there usualy won't be many (or even more than
>> one).
>
> You may find it useful to turn on the transactionlog option, and use
> nbd-trdump. This will give you a good idea of the actual parallelism
> of requests.
>
> Note that if the nbd device ends up being partitioned one way or another
> (for instance because it is exported to kvm, which sees it as a whole
> disk), the parallelism may be more than you think as (AFAIK) n instances
> of an FS will run in parallel.
That is fine. Doing 10 flushes in parallel wouldn't be expensive. As
long as it isn't 10000.
But if we assume Linux block layer behaviour, which seems to be that the
client will only issue a flush after all relevant requests have
completed first, then a FLUSH doesn't have to wait for any pending
requests and can just run fsync() and reply. Which would be the cheapest
to implement.
I'm fine with that behaviour if that is what Linux expects and does. But
it needs to be specified somewhere.
MfG
Goswin
------------------------------------------------------------------------------
vRanger cuts backup time in half-while increasing security.
With the market-leading solution for virtual backup and recovery,
you get blazing-fast, flexible, and affordable data protection.
Download your free trial now.
http://p.sf.net/sfu/quest-d2dcopy1
_______________________________________________
Nbd-general mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/nbd-general
