> Actually, a write to memory for a memory mapped file is more similar to
> write(2). If two programs have the same file mapped then the effect on the
> memory they share is instantaneous because it is the same physical memory.
> A mmapped file becomes shared memory as soon as it is mapped at leas
On Wed, 4 Jul 2012, Stefan Ring wrote:
I really makes no sense at all to
have munmap(2) not imply msync(3C).
Why not? munmap(2) does basically the equivalent of write(2). In the
case of write, that is: a later read from the same location will see
the written data, unless another write happens
On Wed, 4 Jul 2012, Nico Williams wrote:
Oddly enough the manpages at the Open Group don't make this clear. So
I think it may well be advisable to use msync(3C) before munmap() on
MAP_SHARED mappings. However, I think all implementors should, and
probably all do (Linux even documents that it d
On 2012-Jul-05 06:47:36 +1000, Nico Williams wrote:
>On Wed, Jul 4, 2012 at 11:14 AM, Bob Friesenhahn
> wrote:
>> On Tue, 3 Jul 2012, James Litchfield wrote:
>>> Agreed - msync/munmap is the only guarantee.
>>
>> I don't see that the munmap definition assures that anything is written to
>> "disk".
> I really makes no sense at all to
> have munmap(2) not imply msync(3C).
Why not? munmap(2) does basically the equivalent of write(2). In the
case of write, that is: a later read from the same location will see
the written data, unless another write happens in-between. If power
goes down followin
On 07/04/12 16:47, Nico Williams wrote:
I don't see that the munmap definition assures that anything is written to
"disk". The system is free to buffer the data in RAM as long as it likes
without writing anything at all.
Oddly enough the manpages at the Open Group don't make this clear. So
I
On Wed, Jul 4, 2012 at 11:14 AM, Bob Friesenhahn
wrote:
> On Tue, 3 Jul 2012, James Litchfield wrote:
>> Agreed - msync/munmap is the only guarantee.
>
> I don't see that the munmap definition assures that anything is written to
> "disk". The system is free to buffer the data in RAM as long as it
On Tue, 3 Jul 2012, James Litchfield wrote:
Agreed - msync/munmap is the only guarantee.
I don't see that the munmap definition assures that anything is
written to "disk". The system is free to buffer the data in RAM as
long as it likes without writing anything at all.
Bob
--
Bob Friesenh
Agreed - msync/munmap is the only guarantee.
On 07/ 3/12 08:47 AM, Nico Williams wrote:
On Tue, Jul 3, 2012 at 9:48 AM, James Litchfield
wrote:
On 07/02/12 15:00, Nico Williams wrote:
You can't count on any writes to mmap(2)ed files hitting disk until
you msync(2) with MS_SYNC. The system s
On Tue, Jul 3, 2012 at 9:48 AM, James Litchfield
wrote:
> On 07/02/12 15:00, Nico Williams wrote:
>> You can't count on any writes to mmap(2)ed files hitting disk until
>> you msync(2) with MS_SYNC. The system should want to wait as long as
>> possible before committing any mmap(2)ed file writes
inline
On 07/02/12 15:00, Nico Williams wrote:
On Mon, Jul 2, 2012 at 3:32 PM, Bob Friesenhahn
wrote:
On Mon, 2 Jul 2012, Iwan Aucamp wrote:
I'm interested in some more detail on how ZFS intent log behaves for
updated done via a memory mapped file - i.e. will the ZIL log updates done
to an m
On Mon, Jul 2, 2012 at 3:32 PM, Bob Friesenhahn
wrote:
> On Mon, 2 Jul 2012, Iwan Aucamp wrote:
>> I'm interested in some more detail on how ZFS intent log behaves for
>> updated done via a memory mapped file - i.e. will the ZIL log updates done
>> to an mmap'd file or not ?
>
>
> I would to expec
On Mon, 2 Jul 2012, Iwan Aucamp wrote:
I'm interested in some more detail on how ZFS intent log behaves for updated
done via a memory mapped file - i.e. will the ZIL log updates done to an
mmap'd file or not ?
I would to expect these writes to go into the intent log unless
msync(2) is used o
13 matches
Mail list logo
