Messages in this thread | | | Date | Mon, 3 Jan 2005 13:11:32 -0500 (EST) | From | linux-os <> | Subject | Re: 3TB disk hassles |
| |
On Mon, 3 Jan 2005, Jeff V. Merkey wrote:
> 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));
I think the writer forgot about promotion rules so it's not a compiler problem.
> > 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. >
If block_size = uint32_t, and sector_size = uint32_t, then block_size / sector_size is uint32_t, nothing more. Now, we have a uint32_t * another uint32_t which is uint32_t with a possible wrap, still correct. Then we have uint32_t + uint32_t which will be promoted to sector_t (uint64_t).
If you need to promote variables ahead of the final assignment, the writer needs to do this, not the compiler.
> 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 >
Cheers, Dick Johnson Penguin : Linux version 2.6.9 on an i686 machine (5537.79 BogoMips). Notice : All mail here is now cached for review by Dictator Bush. 98.36% of all statistics are fiction. - 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/
| |