> -----Original Message----- > From: Erik Trulsson [mailto:[EMAIL PROTECTED] > Sent: Tuesday, September 25, 2007 5:27 AM > To: Ted Mittelstaedt > Cc: Bart Silverstrim; Chris Boyd; freebsd-questions@freebsd.org > Subject: Re: Update on data corruption with Tyan/3Ware > > > Bart and Chris, > > > > The problem might be that the 3ware driver uses a 32 bit "int" to > > represent > > a file size. > > The 3ware driver handles blocks on the device. It knows nothing > about files or their sizes. That is the job of the filesystem > which resides > at a higher level in the OS. > > It is true that the 3ware twe(4) driver uses 32-bit ints to represent the > *disk* size in number of disk-blocks. With the standard 512-byte > block size > this gives a maximum disk size of (512*4G==) 2TB, which is a known > limitation of the twe(4) driver as well as many other disk controllers. > Anyways the twa(4) driver is supposed to handle volumes larger than 2TB. > > (twe(4) handles 3ware 7000 and 8000-series controllers, while the twa(4) > driver is for the 9000-series.) >
Your right, I missed that. > > In FreeBSD, stat() ftruncate() lseek() and > > friends which are based on "strut stat" had this limitation > under FreeBSD > > 4.xx. > > > > Note line# 821 of twe_freebsd.c the driver: > > > > sc->twed_disk->d_maxsize = (TWE_MAX_SGL_LENGTH - 1) * PAGE_SIZE; > > sc->twed_disk->d_sectorsize = TWE_BLOCK_SIZE; > > sc->twed_disk->d_mediasize = TWE_BLOCK_SIZE * > > (off_t)sc->twed_drive->td_size; > > sc->twed_disk->d_fwsectors = sc->twed_drive->td_sectors; > > > > that off_t also appears elsewhere. > > Since off_t is a 64-bit type, and since none of that code fragment has > anything to do with *file* sizes, I am not sure what your point is. > This isn't true, it is OS dependent. On FreeBSD 64 bit it may be a long long but it isn't on all UNIXes. (particularly old ones) That is why GNU/Linux has (or had) off64_t It's my understanding the twa/twe drivers have a binary "blob" that they loads. You don't know what architecture this blob was compiled under. I merely pointed out use of this code fragment to illustrate a point, not to state that this was a bug in the driver to indicate that it may be possible the blob as a limitation of some kind. Since Bart Silverstrim says he is storing >4GB files without trouble under Linux, I would ASSUME the limitation ISN'T in the 3ware hardware. Apparently you missed the post from Chris that states: "...FreeBSD 6.2 AMD64 with all patches as of 9-21-2007..." "...We've narrowed the problem down to files that are > 4GB. Anytime we have a file that's > 4GB, we get inconsistent checksums, can't uncompress it, etc. Files < 4GB are fine..." So as I already stated the VERY FIRST RESPONSE that Chris needs to go to 3ware and ask them what is going on. Unless your going to continue to say that FreeBSD64 has a 4GB filesize limitation? Ted _______________________________________________ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
