lkml.org 
[lkml]   [2005]   [Jan]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 14:09    [W:0.081 / U:0.308 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site