Re: [fuse-devel] fuse mmap( ) size limitations?

[Xiangyong (S. O. <ou...@cs...>]

On Fri, Apr 8, 2011 at 4:23 AM, Goswin von Brederlow <gos...@we...>wrote:

> "Xiangyong (Shangyong) Ouyang" <ou...@cs...> writes:
>
> > Hello Goswin,
> >
> > Thank you very much for your reply!  It looks like something is wrong
> with my
> > code.  I'm able to mmap() now.
> >
> > Why do you unlink the file after truncate( )?   For safety?
>
> 1) nobody else can later open the file and mess around with the data
> while it is still mapped. So some safety bonus there. But they could
> open it in the split second between open and unlink. For real security
> the name must be unpredictable or in a subdir others don't have access
> to.
>
> 2) I don't want to leave garbage behind. If I don't unlink it now I then
> need to unlink it later. And the program might exit with an error,
> segfault or be killed by the user. Since I don't need the file anymore I
> can unlink it now. It will remain as orphaned file as long as the FD is
> open and get really deleted when the FD is closed or the program is
> killed.
>
> > Also I noticed if I use "MAP_PRIVATE" as the flag then mmap() failed and
> return
> > -1.   Is there a specific reason for that?  Thanks!
>
> That would be a problem with your memory overcomit setting. MAP_PRIVATE
> does not store changes in the file so at worst it will need to keep the
> full file in memory, all your 100G. And you probably don't have that
> much swap nor allowed the kernel to reserve way more memory than it can
> possible back with swap.
>
>
I see.  "MAP_PRIVATE" performs copy-on-write to create private mappings.  It
essentially has to store all mapped space in VM, which is way bigger than
the main mem+swap space.   Thanks a lot Goswin!!




> MfG
>         Goswin
>