From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752967AbcAGJ7X (ORCPT ); Thu, 7 Jan 2016 04:59:23 -0500 Received: from smtp-out-no.shaw.ca ([64.59.134.13]:54313 "EHLO smtp-out-no.shaw.ca" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752052AbcAGJ7T (ORCPT ); Thu, 7 Jan 2016 04:59:19 -0500 X-Authority-Analysis: v=2.1 cv=AMkI9oPf c=1 sm=1 tr=0 a=lgQzZrHfYv1Gyu7gjg9w9A==:117 a=lgQzZrHfYv1Gyu7gjg9w9A==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=IkcTkHD0fZMA:10 a=htZycQqltgF3K9a4D24A:9 a=QEXdDO2ut3YA:10 Message-ID: <568E36F1.9030805@mail.usask.ca> Date: Thu, 07 Jan 2016 11:59:13 +0200 From: Chris Friesen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: lkml Subject: close() behaviour changes depending on whether file exists or not? Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfNM/ejAGmP4g6r61cllns7MYw6X5y+6Feya7vN6mvkBfv3cZiDhWSQxu6Kdr86k41K/TJCKg5Z9IgYm1hBsaaSs8U8soD+RiaKurDpOfuR+2rh20ml62 QbnhsDXXfjB+pswGuPwAX5dfQ6kqffoeHmdOil7jzQeiSxUoPmBtIBG/CoBNE92XFvj5uwtA1rej9A== Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org I'm running 3.14 on my laptop, and I'm seeing some unexpected behaviour when I write out to a big file. Basically if the If I run strace dd if=/dev/zero of=bigfile bs=1M count=1000;cat /proc/meminfo |egrep "Dirty|Writeback" I see the final close() of "bigfile" (fd 1 in the strace output) complete right away, and I get speeds of 1.5GB/s. When it completes I see "Dirty" in /proc/meminfo right at about a GB of data. However, if I then immediately repeat the test (so the "bigfile" file exists already) I see the final close() delay until the writeback is done, almost as though there is an implicit fsync() call. When it completes /proc/meminfo has a "Dirty" value of basically nothing and a "Writeback" value of about 67MB. Is this a known issue? I checked a 3.10 kernel that I had hanging around and it showed the same behaviour. Thanks, Chris PS: Please CC me on reply, I'm not subscribed to the list.