Re: 3TB disk hassles

["Jeff V. Merkey" <jmerkey@drdos.com>]

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