After your message i tried to play a bit with dd. Bad idea.
I did 'dd if=/dev/zero of=test bs=1024k seek=2G' in a 10Gb ide disk, and
guess what ?
$ ls -l test
-rw-r--r-- 1 huma huma 2251799813685248 Nov 15 02:39 test
$ ls -lh test
-rw-r--r-- 1 huma huma 2.0P Nov 15 02:39 test
Yep, it says i have a 2 Petabyte file in a 10gb drive. Something is
_really_ broken here.
Deleting this file gave me some errors like this:
Nov 15 01:50:07 fargo kernel: EXT2-fs error (device ide3(34,1)):
ext2_free_blocks: Freeing blocks not in datazone - block = 161087505,
count = 1
Nov 15 01:50:07 fargo kernel: EXT2-fs error (device ide3(34,1)):
ext2_free_blocks: Freeing blocks not in datazone - block = 161153041,
count = 1
After that, i unmounted the partition and did an fsck, lots of errors and
several files corrupted that fsck ask me to delete because some inodes had
illegal blocks.
By the way, is a ext2 partition. Versions are: kernel 2.4.14, fileutils
4.1 and glibc 2.2.3.
> Hello,
> I was recently testing a bit with creating very large files on ext2/ext3
> (just to see if limits were what they should be). Now, I know that ext2/3
> allows files just shy of 2TB right now, because of an issue with i_blocks
> being in units of 512-byte sectors, instead of fs blocks.
>
> I tried to create a (sparse!) file of 2TB size with:
>
> dd if=/dev/zero of=/tmp/tt bs=1k count=1 seek=2047M
>
> and it worked fine (finished immediately, don't try this with reiserfs...).
>
> When I tried to make it just a bit bigger, with:
>
> dd if=/dev/zero of=/tmp/tt bs=1k count=1 seek=2048M
>
> dd fails the "llseek(fd, 2T, SEEK_SET)" with -EINVAL, and then proceeds
> to loop "infinitely" reading from the file to try and manually advance
> the file descriptor offset to the desired offset. That is bad.
>
> I _think_ there is a bug in generic_file_llseek(), with it returning -EINVAL
> instead of -EFBIG in the case where the offset is larger than the s_maxbytes.
> AFAICS, the return -EINVAL is for the case where "whence" is invalid, not the
> case where "offset" is too large for the underlying filesystem (I can see
> -EINVAL for seeking to a negative position).
>
> If I use:
>
> dd if=/dev/zero of=/tmp/tt bs=1k count=1025 seek=2097151k
>
> I correctly get "EFBIG (file too large)" and "SIGXFSZ" from write(2).
>
> Does anyone know the correct LFS interpretation on this? From what I can
> see (I have not read the whole thing) lseek() should return EOVERFLOW if
> the resulting offset is too large to fit in the passed type. It doesn't
> really say what should happen in this particular case - can someone try
> on a non-Linux system and see what the result is?
>
> Either way, I think the kernel is broken in this regard.
>
> Cheers, Andreas
> --
> Andreas Dilger
> http://sourceforge.net/projects/ext2resize/
> http://www-mddsp.enel.ucalgary.ca/People/adilger/
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
David Gómez
"The question of whether computers can think is just like the question of
whether submarines can swim." -- Edsger W. Dijkstra
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Nov 15 2001 - 21:00:41 EST