Prev: Problem with getopt_long_only() (GNU/Linux)
Next: NETWORK MARKETING
From: yirgster on 10 May 2010 15:01
On May 10, 8:57 am, Chris Friesen <cbf...(a)mail.usask.ca> wrote:
> On 05/10/2010 09:46 AM, Chris Friesen wrote:
>
> > I don't think that's correct.  Last I checked fsync() didn't walk the
> > page tables looking for dirty pages to flush, while msync() does.
>
> Looks like I was wrong and they now do that.
>
> Chris

But, from a "legal" standpoint,

(1) this isn't required behavior by posix, that is, that fsync(fd)
sync all mmap'd(fd) memory too.

but it won't be much of a performance hit because if it does then

(2) the fsync() following the msync(MS_SYNC) will find the pte's clean
and hence will NOT rewrite the page again.

Note that in windows you MUST do both analogous operations.

Flushing a range of a mapped view initiates writing of dirty pages
within that range to the disk. Dirty pages are those whose contents
have changed since the file view was mapped. The FlushViewOfFile
function does not flush the file metadata, and it does not wait to
return until the changes are flushed from the underlying hardware disk
cache and physically written to disk. To flush all the dirty pages
plus the metadata for the file and ensure that they are physically
written to disk, call FlushViewOfFile and then call the
FlushFileBuffers function. http://msdn.microsoft.com/en-us/library/aa366563%28VS.85%29.aspx
From: Chris Friesen on 10 May 2010 15:41
On 05/10/2010 01:01 PM, yirgster wrote:

> But, from a "legal" standpoint,
>
> (1) this isn't required behavior by posix, that is, that fsync(fd)
> sync all mmap'd(fd) memory too.

Contrary to Rainer, I think it actually might be implied by posix, and
that's why the various OS's have changed their behaviour.

The posix language reads "all data for the open file descriptor named by
fildes is to be transferred to the storage device associated with the
file described by fildes." Arguably, memory ranges mmap'd from a file
is "data for the open file descriptor".

However, we know that historically this hasn't been the case so it would
be silly to rely on this behaviour to be portable.

> but it won't be much of a performance hit because if it does then
>
> (2) the fsync() following the msync(MS_SYNC) will find the pte's clean
> and hence will NOT rewrite the page again.

True.

Chris
From: yirgster on 10 May 2010 16:04
On May 10, 12:41 pm, Chris Friesen <cbf...(a)mail.usask.ca> wrote:
> On 05/10/2010 01:01 PM, yirgster wrote:
>
> > But, from a "legal" standpoint,
>
> > (1) this isn't required behavior by posix, that is, that fsync(fd)
> > sync all mmap'd(fd) memory too.
>
> Contrary to Rainer, I think it actually might be implied by posix, and
> that's why the various OS's have changed their behaviour.
>
> The posix language reads "all data for the open file descriptor named by
> fildes is to be transferred to the storage device associated with the
> file described by fildes."  Arguably, memory ranges mmap'd from a file
> is "data for the open file descriptor".

Chris, as you say: "arguably". This is a case where, imo, the spec
needs to be explicitly explicit, especially due to historically known
behavior. So, wrt to the spec I think "not guaranteed" even if
guaranteed is the current intent.

Are there means to get such language made more explicit? Is there a
"grand committee" than can be appealed to?

>
> However, we know that historically this hasn't been the case so it would
> be silly to rely on this behaviour to be portable.
>
> > but it won't be much of a performance hit because if it does then
>
> > (2) the fsync() following the msync(MS_SYNC) will find the pte's clean
> > and hence will NOT rewrite the page again.
>
> True.

So this is what I'm going to do, especially as the need to do it
arises very infrequently in our application.

>
> Chris

From: Chris Friesen on 10 May 2010 19:05
On 05/10/2010 02:04 PM, yirgster wrote:
> On May 10, 12:41 pm, Chris Friesen <cbf...(a)mail.usask.ca> wrote:

>> The posix language reads "all data for the open file descriptor named by
>> fildes is to be transferred to the storage device associated with the
>> file described by fildes." Arguably, memory ranges mmap'd from a file
>> is "data for the open file descriptor".
>
> Chris, as you say: "arguably". This is a case where, imo, the spec
> needs to be explicitly explicit, especially due to historically known
> behavior. So, wrt to the spec I think "not guaranteed" even if
> guaranteed is the current intent.
>
> Are there means to get such language made more explicit? Is there a
> "grand committee" than can be appealed to?

I think that would be these folks:

http://www.opengroup.org/austin/

Chris
From: Rainer Weikusat on 12 May 2010 15:33
Chris Friesen <cbf123(a)mail.usask.ca> writes:
> On 05/10/2010 01:01 PM, yirgster wrote:
>
>> But, from a "legal" standpoint,
>>
>> (1) this isn't required behavior by posix, that is, that fsync(fd)
>> sync all mmap'd(fd) memory too.
>
> Contrary to Rainer, I think it actually might be implied by posix, and
> that's why the various OS's have changed their behaviour.
>
> The posix language reads "all data for the open file descriptor named by
> fildes is to be transferred to the storage device associated with the
> file described by fildes." Arguably, memory ranges mmap'd from a file
> is "data for the open file descriptor".

The situation isn't that simple, eg, it is legal to close a file
descriptor after it was used to establish a memory mapping and to
continue using the mapping. Assuming that the file is later reopened,
is whatever the existing memory mapping contains necessarily 'data for
the new file descriptor' (or only if the implementation happens to
have a unified cache)?
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: Problem with getopt_long_only() (GNU/Linux)
Next: NETWORK MARKETING