From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:56394)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <owasserm@redhat.com>) id 1WBlvx-0000ks-07
	for qemu-devel@nongnu.org; Fri, 07 Feb 2014 08:57:38 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <owasserm@redhat.com>) id 1WBlvq-0005HP-Ta
	for qemu-devel@nongnu.org; Fri, 07 Feb 2014 08:57:32 -0500
Received: from mx1.redhat.com ([209.132.183.28]:24255)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <owasserm@redhat.com>) id 1WBlvq-0005H0-Lo
	for qemu-devel@nongnu.org; Fri, 07 Feb 2014 08:57:26 -0500
Message-ID: <52F4E662.4000803@redhat.com>
Date: Fri, 07 Feb 2014 15:57:54 +0200
From: Orit Wasserman <owasserm@redhat.com>
MIME-Version: 1.0
References: <52F46298.8020602@ozlabs.ru>	<52F48F3A.40606@redhat.com>	<52F4CD3E.1000809@ozlabs.ru>	<52F4D5C6.1050206@redhat.com>
	<52F4D778.6070001@beyond.pl> <52F4E15E.3020109@redhat.com>
	<52F4E33B.4070305@beyond.pl>
In-Reply-To: <52F4E33B.4070305@beyond.pl>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Subject: Re: [Qemu-devel] migration question: disk images on nfs server
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: =?UTF-8?B?TWFyY2luIEdpYnXFgmE=?= <m.gibula@beyond.pl>, Alexey Kardashevskiy <aik@ozlabs.ru>, qemu-devel@nongnu.org

On 02/07/2014 03:44 PM, Marcin Gibu=C5=82a wrote:
> On 07.02.2014 14:36, Orit Wasserman wrote:
>>> Do you know if is applies to linux O_DIRECT writes as well?
>>>
>>
>>  From the man of open:
>>
>>         The behaviour of O_DIRECT with NFS will differ from local
>>         filesystems.  Older kernels, or kernels configured in certain =
ways,
>>         may not support this combination.  The NFS protocol does not
>> support
>>         passing the flag to the server, so O_DIRECT I/O will bypass th=
e
>> page
>>         cache only on the client; the server may still cache the I/O. =
 The
>>         client asks the server to make the I/O synchronous to preserve=
 the
>>         synchronous semantics of O_DIRECT.  Some servers will perform
>> poorly
>>         under these circumstances, especially if the I/O size is small.
>> Some
>>         servers may also be configured to lie to clients about the I/O
>> having
>>         reached stable storage; this will avoid the performance penalt=
y at
>>         some risk to data integrity in the event of server power failu=
re.
>>         The Linux NFS client places no alignment restrictions on O_DIR=
ECT
>>         I/O.
>>
>> To summaries it depends on your kernel (NFS client).
>
> So, assuming new kernel (where nfs O_DIRECT translates to no cache at c=
lient side) and cache coherent server, is it enough or is 'sync' mount (o=
r O_SYNC flag) still required for some reason?
>

I think is should be enough.