Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 08 Jun 2005 12:33:06 -0400
From:      Paul Mather <paul@gromit.dlib.vt.edu>
To:        freebsd-current@freebsd.org
Cc:        "Raphael H. Becker" <rabe@p-i-n.com>
Subject:   Re: Accessing SCSI-Devices >2TB
Message-ID:  <1118248386.7479.10.camel@zappa.Chelsea-Ct.Org>
In-Reply-To: <20050608152459.BF24E16A45C@hub.freebsd.org>
References:  <20050608152459.BF24E16A45C@hub.freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 8 Jun 2005 17:24:35 +0200, "Raphael H. Becker" <rabe@p-i-n.com>
wrote:

> On Wed, Jun 08, 2005 at 11:01:52PM +0800, Xin LI wrote:
> 
> > > Well, I'm pretty trained in configuring that RAID now so if anyone
> knows 
> > > a solution, how to get rid of the 2TB-Limit for one drive
> (/dev/da1),
> > > maybe using larger blocks of about 1k or 2k, I just need to
> configure
> > > that RAID as a single large logical drive. 
> > > 
> > > Just tell me about the blocksizes (see other mail).
> > 
> > Err...  You don't need to play with the drivers/CAM stuff, why not
> try the
> > natively supported gpt(8), which works great.
> > 
> >       - Map the RAID device to a single SCSI device
> >       - Do a dd if=/dev/zero of=/dev/da0 bs=16384 count=16 to wipe
> the MBR
> 
> Well, without a /dev/daX there's nothing to use gpt with. The kernel
> itself cannot access the RAID as a whole. See my other mail for the
> kernel messages.
> 
> My workaround was to partition the RAID's logical disc into two
> partitions 
> internally and re-concat the resulting da1 and da2 into ccd0.
> But this might also be a bad idea therefore ccd0 is will do stripes
> and
> the RAID will have to seek the physikal drives a lot for each (linear)
> access.
> 
> Two solutions:
> a) FreeBSD can access the RAID using LBA64 and get a da1 having
> ~2.5TB 
> 
> b) I have to split the RAID on physical drive layer, having 6 disks
> for
> each logical drive (losing hot-spare (cannot divide 11 discs into 2
> equal logical drives) and need a additional parity, one for each
> logical
> drive) and mapping those to two different LUNs or IDs and using the
> resulting 
> 1.3TB-drives da1 and da2 with ccd(4) and then ...  
> 
> >       - Do a `gpt create /dev/da0' to create your GPT partition
> table
> >       - Do a `gpt add /dev/da0' to create a GPT partition over it
> >       - You will now see something like /dev/da0p1, which can be
> used for
> >         subsequent disklabel(8), or just newfs -U /dev/da0p1
> 
> ... will try this, if the device is clear. Thank you for the hint
> about gpt.

You might want to check the "Large data storage in FreeBSD" project page
(http://www.freebsd.org/projects/bigdisk/) for an audit of other issues
relating to large filesystems in FreeBSD.  I don't know how up to date
the page is (it reports being last modified mid-February, 2005), but
currently it still lists various issues with some userland tools and
subsystems not being 64-bit clean.

Also, have you considered using geom_stripe for concatenation?  It
postdates ccd.  See the gstripe(8) man page for details.

Cheers,

Paul.
-- 
e-mail: paul@gromit.dlib.vt.edu

"Without music to decorate it, time is just a bunch of boring production
 deadlines or dates by which bills must be paid."
        --- Frank Vincent Zappa



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1118248386.7479.10.camel>