From: linux-os <linux-os@chaos.analogic.com>
To: "Jeff V. Merkey" <jmerkey@drdos.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>,
Andries Brouwer <aebr@win.tue.nl>,
linux-kernel@vger.kernel.org
Subject: Re: 3TB disk hassles
Date: Mon, 3 Jan 2005 13:11:32 -0500 (EST) [thread overview]
Message-ID: <Pine.LNX.4.61.0501031248200.13136@chaos.analogic.com> (raw)
In-Reply-To: <41D98197.3050404@drdos.com>
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.
next prev parent reply other threads:[~2005-01-03 18:21 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-12-16 14:52 3TB disk hassles Neil Conway
2004-12-16 15:33 ` Michelle Konzack
2004-12-16 15:37 ` Mark Watts
2004-12-16 15:38 ` Hans Kristian Rosbach
2004-12-16 16:44 ` Neil Conway
2004-12-16 17:15 ` Tomas Carnecky
2004-12-16 17:38 ` Neil Conway
2004-12-16 18:05 ` Tomas Carnecky
2005-02-05 1:47 ` Neil Conway
2004-12-16 17:40 ` Tomas Carnecky
2004-12-16 15:52 ` Michelle Konzack
2004-12-16 16:03 ` Jan Engelhardt
2004-12-16 16:00 ` Alan Cox
2004-12-18 0:12 ` Andries Brouwer
2004-12-18 3:08 ` H. Peter Anvin
2004-12-18 12:15 ` Andries Brouwer
2004-12-18 23:32 ` H. Peter Anvin
2005-01-03 17:13 ` Jeff V. Merkey
2005-01-03 17:32 ` Jeff V. Merkey
2005-01-03 18:11 ` linux-os [this message]
2004-12-16 17:10 ` Michelle Konzack
2004-12-16 19:52 ` Adam Heath
2004-12-16 23:28 ` Pedro Venda (SYSADM)
2005-02-05 1:51 ` Neil Conway
2004-12-16 22:21 Rico Tudor
[not found] <fa.fng0mbi.10jm21g@ifi.uio.no>
[not found] ` <fa.ls0rpqi.104a23q@ifi.uio.no>
2005-02-05 2:58 ` Bodo Eggert
2005-02-05 11:14 ` Neil Conway
2005-02-06 10:59 Neil Conway
2005-02-06 19:01 ` Bodo Eggert
2005-02-08 23:33 ` H. Peter Anvin
[not found] <linux.kernel.20041216145229.29167.qmail@web26502.mail.ukl.yahoo.com>
2005-02-10 0:06 ` Jan Lindheim
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Pine.LNX.4.61.0501031248200.13136@chaos.analogic.com \
--to=linux-os@chaos.analogic.com \
--cc=aebr@win.tue.nl \
--cc=hpa@zytor.com \
--cc=jmerkey@drdos.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-os@analogic.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).