> -----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?

freebsd-questions@freebsd.org mailing list
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to