pcp
[Top] [All Lists]

Re: [pcp] pmlogrewrite questions from the developer meeting

To: Nathan Scott <nathans@xxxxxxxxxx>
Subject: Re: [pcp] pmlogrewrite questions from the developer meeting
From: Ken McDonell <kenj@xxxxxxxxxxxxxxxx>
Date: Tue, 15 Apr 2014 08:52:43 +1000
Cc: pcp@xxxxxxxxxxx
Delivered-to: pcp@xxxxxxxxxxx
In-reply-to: <379318588.4720106.1397436550627.JavaMail.zimbra@xxxxxxxxxx>
References: <01c501cf56de$54b6d370$fe247a50$@internode.on.net> <379318588.4720106.1397436550627.JavaMail.zimbra@xxxxxxxxxx>
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
On 14/04/14 10:49, Nathan Scott wrote:
...
There is a metadata vs data ordering assumption, I believe.  We need to fsync
the newly created data files before the rename otherwise we could end up with
empty files on-disk - or files-filled-with-zeroes depending on the filesystem
implementation (in this case: directory metadata IO & new file inode metadata
IO completes up to the open(O_CREAT), but no data writes/allocation happen).

Nathan,

So before exit(), you're sugesting fsync() on each of the data files, and I think I need fsync() on the container directory as well.

But we should be consistent. If this is the "right" way to do it then surely all applications that can write PCP archives should do the same thing.

I am not against doing this, although if one was concerned at this level then I suspect an option to enforce O_SYNC might be better to guarantee on disk for all writes, not just flushing everything at exit, but we should choose one policy for writing PCP archives and implement it consistently throughout the PCP ecosystem.

<Prev in Thread] Current Thread [Next in Thread>