From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf0-f72.google.com (mail-lf0-f72.google.com [209.85.215.72]) by kanga.kvack.org (Postfix) with ESMTP id D9DD36B0033 for ; Wed, 11 Jan 2017 05:55:21 -0500 (EST) Received: by mail-lf0-f72.google.com with SMTP id o12so49881187lfg.7 for ; Wed, 11 Jan 2017 02:55:21 -0800 (PST) Received: from mail-lf0-x234.google.com (mail-lf0-x234.google.com. [2a00:1450:4010:c07::234]) by mx.google.com with ESMTPS id g83si3265027ljg.70.2017.01.11.02.55.20 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Jan 2017 02:55:20 -0800 (PST) Received: by mail-lf0-x234.google.com with SMTP id k86so134303175lfi.0 for ; Wed, 11 Jan 2017 02:55:20 -0800 (PST) From: Chris Vest Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_9F176A49-27D3-41FD-80A2-359837F436F6" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: [LSF/MM TOPIC] I/O error handling and fsync() Date: Wed, 11 Jan 2017 11:55:18 +0100 In-Reply-To: <20170111050356.ldlx73n66zjdkh6i@thunk.org> References: <20170110160224.GC6179@noname.redhat.com> <20170111050356.ldlx73n66zjdkh6i@thunk.org> Sender: owner-linux-mm@kvack.org List-ID: To: Theodore Ts'o Cc: Kevin Wolf , lsf-pc@lists.linux-foundation.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, Christoph Hellwig , Ric Wheeler , Rik van Riel --Apple-Mail=_9F176A49-27D3-41FD-80A2-359837F436F6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 11 Jan 2017, at 06.03, Theodore Ts'o wrote: >=20 > So an approach that might work is fsync() will keep the pages dirty > --- but only while the file descriptor is open. This could either be > the default behavior, or something that has to be specifically > requested via fcntl(2). That way, as soon as the process exits (at > which point it will be too late for it do anything to save the > contents of the file) we also release the memory. And if the process > gets OOM killed, again, the right thing happens. But if the process > wants to take emergency measures to write the file somewhere else, it > knows that the pages won't get lost until the file gets closed. I think this sounds like a very reasonable default. Before reading this = thread, it would have been my first guess as to how this worked. It = gives the program the opportunity to retry the fsyncs, before aborting. = It will also allow a database, for instance, to keep servicing reads = until the issue resolves itself, or an administrator intervenes. A = program cannot allow reads from the file if pages that has been written = to can be evicted, and their changes lost, and then brought back with = old data. -- Chris Vest --Apple-Mail=_9F176A49-27D3-41FD-80A2-359837F436F6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On 11 Jan 2017, at 06.03, Theodore Ts'o <tytso@mit.edu> = wrote:

So an approach that might work is fsync() will = keep the pages dirty
--- but only while the file descriptor is = open.  This could either be
the default behavior, or = something that has to be specifically
requested via fcntl(2). =  That way, as soon as the process exits (at
which point it will be too late for it do = anything to save the
contents of the file) we also release the = memory.  And if the process
gets OOM killed, again, the = right thing happens.  But if the process
wants to take emergency measures to write the = file somewhere else, it
knows that the pages won't get lost until = the file gets closed.

I think this sounds like a very reasonable default. = Before reading this thread, it would have been my first guess as to how = this worked. It gives the program the opportunity to retry the fsyncs, = before aborting. It will also allow a database, for instance, to keep = servicing reads until the issue resolves itself, or an administrator = intervenes. A program cannot allow reads from the file if pages that has = been written to can be evicted, and their changes lost, and then brought = back with old data.

--
Chris Vest
= --Apple-Mail=_9F176A49-27D3-41FD-80A2-359837F436F6-- -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org