CNFS buffers bigger than 2 GB under Linux ?

["Miquel van Smoorenburg"]

In article <ylofhlzo96.fsf at windlord.stanford.edu>,
Russ Allbery  <rra at stanford.edu> wrote:
>INN imposes no limitations; the limitation is in the kernel.  It's a
>common limitation; I don't know of any operating system at present that
>supports memory mapping raw devices over 2GB.  (Tru64, probably, if it
>supports mmap on raw devices at all, but I'm not sure it does.)

Linux can mmap block-devices over 2GB. What it cannot do is mmap()
more than 2 GB at the same time on a 32 bit platform, because it
doesn't fit in the address space. That's a limitation of the 32bit
platform. But that should not be an issue, INN only maps small parts
of the file at a time, right?

The test program below will confirm if mmap() works over 2GB.
Call it as "a.out /dev/large-disk-or-partition". (or a.out /dev/zero).

BTW, note that there is a difference between block devices and
raw devices on most platforms. A raw device is usually a characterdevice
that corresponds to a blockdevice (on linux it's a special device
that you have to 'bind' to a blockdevice). A raw device circumvents
the systems diskcache - it's only used if you specifically do not
want to use the kernels diskcache. With INN, you really really DO
want to use that cache - so don't use a raw device, use the block device.



#define _LARGEFILE_SOURCE
#define _FILE_OFFSET_BITS 64

#include <stdio.h>
#include <fcntl.h>
#include <unistd.h>
#include <sys/mman.h>

off_t fivegb = 0x140000000;
off_t onegb = 0x40000000;

int main(int argc, char **argv)
{
	caddr_t	a;
	int fd;

	if (onegb == fivegb) {
		printf("This platform has no largefile support\n");
		exit(1);
	}

	if ((fd = open(argv[1], O_RDONLY)) < 0) {
		perror(argv[1]);
		exit(1);
	}

	if ((a = mmap(NULL, 4096, PROT_READ, MAP_SHARED, fd, fivegb)) ==
	    (caddr_t)-1) {
		perror("mmap");
		exit(1);
	}
	printf("succesfully mapped 4096 bytes at 5 GB offset\n");

	return 0;
}



Mike.

-- 
The From: and Reply-To: addresses are internal news2mail gateway addresses.
Reply to the list or to "Miquel van Smoorenburg" <miquels at cistron.nl>