On Feb 25, 2005 18:58 -0600, Damian Menscher wrote: > On Fri, 25 Feb 2005, Andreas Dilger wrote: > >I would start by testing whether the large device works properly by > >writing some pattern (e.g. 64-bit byte offset) to the start of each > >4k block on disk, and then read them back to verify nothing has been > >overwritten. > > Out of curiosity, how would one do this? All I can think of is to > script something to call dd with the seek/skip argument. But making > 3.5TB/4k = a billion calls to dd out a shell seems kinda silly. What do > you suggest? I'd say a simple C program like the following (not much error checking, untested, be careful ;-): #define _GNU_SOURCE #define _LARGEFILE64_SOURCE #include <stdio.h> #include <stdlib.h> #include <errno.h> #include <string.h> #define BUFSZ 4096 int main() { char buf[BUFSZ] = { 0 }; long long offset, *bufp = (long long *)buf; int fd = open(argv[1], O_RDWR | O_LARGEFILE); int rc; while (write(fd, buf, sizeof(buf)) == sizeof(buf)) *bufp += sizeof(buf); printf("end at %llu: %s\n", lseek64(fd, 0, SEEK_CUR), strerror(errno)); offset = lseek64(fd, 0, SEEK_SET); while (read(fd, buf, sizeof(buf)) == sizeof(buf)) { if (*bufp != offset) fprintf(stderr, "offset %llu data is %llu\n", offset, *bufp); offset += sizeof(buf); } printf("end at %llu: %s\n", lseek64(fd, 0, SEEK_CUR), strerror(errno)); return 0; } > >Next, create directories (you may need as many as 16k) to get one that > >is in the >2TB part of the disk. You can tell by the inode number and > >the output from dumpe2fs. If you write a file in that directory it > >should allocate space at > 2TB on the disk, and debugfs "stat file" will > >tell you the block layout of the file. > > As I understand it, the first test is to identify if the flaw exists in > the kernel block-device code, and the second test whether the bug is in > the ext2 code? Correct. > Anyone out there actually using a >2TB filesystem on a 32-bit machine? I've heard sporadic reports about it, but there is definitely a problem somewhere after 2TB. For Lustre we don't care so much about gigantic individual filesystems because we aggregate them at a higher level (100's of TB) and having "smaller" (i.e. 2TB) filesystems allows more parallelism for IO, e2fsck, etc. Cheers, Andreas -- Andreas Dilger http://sourceforge.net/projects/ext2resize/ http://members.shaw.ca/adilger/ http://members.shaw.ca/golinux/
Attachment:
pgpL1WoCA33LI.pgp
Description: PGP signature
_______________________________________________ Ext3-users@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/ext3-users