| To: | Steve Lord <lord@xxxxxxx> |
|---|---|
| Subject: | Re: mmap() Limitation |
| From: | Andi Kleen <ak@xxxxxxx> |
| Date: | Wed, 5 Dec 2001 20:49:17 +0100 |
| Cc: | "Quang Nguyen (Ngo)" <quang.nguyen@xxxxxxxxxxxx>, "'linux-xfs@xxxxxxxxxxx'" <linux-xfs@xxxxxxxxxxx> |
| In-reply-to: | <1007579975.22679.28.camel@xxxxxxxxxxxxxxxxxxxx> |
| References: | <ACD4093EB009D411BC8A009027D7699660A15E@xxxxxxxxxxxxxxxxx> <1007579975.22679.28.camel@xxxxxxxxxxxxxxxxxxxx> |
| Sender: | owner-linux-xfs@xxxxxxxxxxx |
| User-agent: | Mutt/1.3.22.1i |
> There does not appear to be a user space interface to mmap out beyond > a 4G boundary on ia32 linux. The mmap64 call is from irix. This looks > like a deficiency in the linux large file support to me. There is actually. In kernel it is called mmap2(), in glibc it should be mmap64() or even default when compiled for largefiles. mmap2 does not pass in a true 64bit offset, but an 32bit scaled by PAGE_SIZE, but that works well enough as the page cache cannot represent bigger files anyways (that is the internal interface between glibc and kernel; the user passes an byte offset to mmap64 of course) -andi |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: Files on XFS not safe?!, Steve Lord |
|---|---|
| Next by Date: | Re: Follow up -- Re: Files on XFS not safe?!, Austin Gonyou |
| Previous by Thread: | Re: mmap() Limitation, Steve Lord |
| Next by Thread: | compilers, Christian, Chip |
| Indexes: | [Date] [Thread] [Top] [All Lists] |