Messages in this thread | | | Date | Mon, 03 Jan 2005 10:32:07 -0700 | From | "Jeff V. Merkey" <> | Subject | Re: 3TB disk hassles |
| |
Jeff V. Merkey wrote:
> H. Peter Anvin wrote: > >> Andries Brouwer wrote: >> >>> >>> Concerning one, it is a somewhat complicated format that takes over >>> your disk, rather inconvenient. It seems to me that one needs a good >>> reason (like a BIOS that understands the format and is able to boot >>> from it) to choose it. >>> >> >> Not really; it's actually a very simple table. >> > > It would be nice to know when this is going to make it in for my Linux > projects. > I am running a 3Ware 9500 series with 3.1 TB disks. I am able to use > all the > storage at present with dsfs. dsfs can support volumes up to 281 TB > at present > but linux readir() can get into some problems when directories get > really large. > > I am not seeing problems with files that are 1.5 TB in size. Have not > tried to > create a 3TB file yet, but in theory, the VFS looks to support it. I > am getting around the > partition problem by basically ignoring the table extents (fdisk is > broken with these large > partitions and wraps back to 700GB) if I have only created a single > partition, I just query > the drive geometry and take the remaining space on the device and I > ignore the partition > table. It works fine. If I detect more than one of my partitions I > revert back to the actual > partition dimensions. > For Jens edification, I am using the BIO subsystem with this and I am > seeing no problems > reading and writing these huge drives, so I think Linux 2.6.9 and > 2.6.10 will support this > well, and appears to. I will be testing a combined striped array at > around 20TB with multiple > controllers and FC/AL and will update if any problems are encountered. > Other than the partition problem, the base kernel seems to support > these huge sizes with > 64 bit LBA addressing very well. > > Jeff >
One other item I noticed is that the compiler for X86 has some problems doing math for a 64 bit target variable, so when you are using Large LBA and doing something like:
sector_t lba = part.start_lba + (block * (block_size / sector_size));
you need to cast the variables if they are defined as 32 bit numbers because the compiler is too stupid to realize you are adding the cumlative result into a 64-bit value, and it will wrap the offset as a 32 bit number.
i.e.
sector_t lba = part.start_lba + (sector_t)((sector_t)block * ((sector_t)block_size / (sector_t)sector_size));
This works but if you leave off the type casting on any of the variables the number reverts to a 32 bit value and wraps when you are calculating a 64 bit lba address.
Jeff
- 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/
| |