Re: Accessing SCSI-Devices >2TB

From: Raphael H. Becker <rabe_at_p-i-n.com>
Date: Wed, 8 Jun 2005 17:24:35 +0200
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.

Regards
Raphael Becker
Received on Wed Jun 08 2005 - 13:24:39 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:36 UTC