public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Jeff V. Merkey" <jmerkey@drdos.com>
To: "H. Peter Anvin" <hpa@zytor.com>
Cc: Andries Brouwer <aebr@win.tue.nl>, linux-kernel@vger.kernel.org
Subject: Re: 3TB disk hassles
Date: Mon, 03 Jan 2005 10:13:48 -0700	[thread overview]
Message-ID: <41D97D4C.9020403@drdos.com> (raw)
In-Reply-To: <41C4BE18.5060404@zytor.com>

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


  reply	other threads:[~2005-01-03 17:05 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 [this message]
2005-01-03 17:32                   ` Jeff V. Merkey
2005-01-03 18:11                     ` linux-os
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
  -- strict thread matches above, loose matches on Subject: below --
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=41D97D4C.9020403@drdos.com \
    --to=jmerkey@drdos.com \
    --cc=aebr@win.tue.nl \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    /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