Re: 64 Bits from Larry McVoy

Jim Nance (jlnance@avanticorp.com)
Wed, 6 Nov 1996 07:20:27 -0500 (EST)


> I patched the program to use _llseek, and to specify a correct mode on
> open ;-).
> I never got a nice printk() from ext2fs. But from a certain file length on
> (I didn't check but I figure it's when 32 bit can't hold the offset any
> more) write fails with EFBIG: File too large. Very normal, controlled
> behaviour...

First I want to thank all the people who pointed out that I don't know how
to use open(). I have patched the program call it correctly, and have
included the errors I am seeing. Also, I am running on an Alpha, not an
intel machine. I would expect compleatly different behavior on an intel
since the longs are only 32 bits. Here is the program:

#include <stdlib.h>
#include <stdio.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>

#define GB ((long)2*(1024*1024*1024)/2)
#define NG (20L)

int main()
{
off_t offset;
int fd = open("bigfile", O_CREAT|O_TRUNC|O_WRONLY, 0666);

if(fd<0) {perror("open:"); exit(1);}

for(offset=0; offset<=NG*GB; offset += GB) {
int num;
off_t pos = lseek(fd, offset, SEEK_SET);
if(pos!=offset) {perror("lseek:"); exit(1);}
num=write(fd,"x",1);
if(num!=1) {perror("write:"); exit(1);}
}

printf("Done!\n");
return 0;
}

When I run it I get this nice message:

scooter> ./a.out
EXT2-fs warning (device 08:18): ext2_getblk: block > big
write:: Input/output error

Now it does make a file:
scooter> ls -l
total 66
-rwxrwxrwx 1 jlnance users 14317 Nov 5 06:53 a.out*
-rw-rw-rw- 1 jlnance users 555 Nov 5 06:53 big.c
-rw-rw-rw- 1 jlnance users 18253611008 Nov 5 06:57 bigfile

This file is much larger than 2G. I think its about 18G. The really
interesting thing is that sometimes it will spontaneously truncate itself:

scooter> dd bs=1k count=10 if=bigfile of=/dev/null
10+0 records in
10+0 records out
scooter> ls -l
total 66
-rwxrwxrwx 1 jlnance users 14317 Nov 5 06:53 a.out*
-rw-rw-rw- 1 jlnance users 555 Nov 5 06:53 big.c
-rw-rw-rw- 1 jlnance users 1073741824 Nov 5 06:57 bigfile

Now its a 1G file :-( I can not always force it to truncate by accessing it,
but it will always eventually truncate itself if you leave it around for
long enough and read from it enough.

For anyone who is interested in trying to reproduce this, I used the 2.0.18
kernel supplied with RedHat 4.0, recompiled with the RedHat 4.0 compiler.
I am running on an Alphastation 200 4/166 with the SRM console.

Thanks,

Jim