Messages in this thread |  | | From | Jim Nance <> | Subject | Re: 64 Bits from Larry McVoy | Date | 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
|  |