John Pappas j at jvpappas.net
Sat Feb 19 14:19:06 CST 2011

On Thu, Feb 17, 2011 at 18:13, mark <mark at kandm-solutions.com> wrote:

> have you tried reading from the drive in linux after loading the
> dmraid module?

I am a bit late to this thread, but if I understand correctly, you are doing
a mirror (RAID1) via a Hardware-Assisted Software RAID controller.  IN this
case, the drive is almost a standard format (minus the RAID superblock and
any other header info the driver writes to ID the spindle as part of the
raidset.  You should be able to mount the file system directly via linux
(presumably you have a single, simple partition formatted with NTFS as
this originated on windows (Note that if you are using GPT or the RAID is
formated as a Dynamic Disk, that is a completely different discussion, and
nothing said here applies).

> My understanding is that pretty much all raid controllers, software or
> hardware, require a driver. I believe the dmraid module works for most
> of the onboard sata raid controllers.

True, but in the case of a true-hardware RAID controller, the individual
spindles will not be directly visible to any OS, unless the controller is
configured to present the disks as JBOD.  Any disk involved in a true
hardware raidset will be invisible, and only the raidset volume will be
visible to the OS as a "drive".  In many cases the controller and RAID
volume is visible to any OS, and does not specifically need a driver to do
basic manipulations.  For example, I have used SpinRite6 on a HP Proliant
RAID volume directly, and SpinRite does not contain nor load the CCISS
driver that the HP Proliant RAID controllers use.

Now, the caveats are that in the case of a bootable RAID setup or if you
want visibility/control into/of the RAID configuration, a driver is most
often needed to allow the OS to make API calls to the controller itself,
rather than just see the raidset storage.

> On Thu, 2011-02-17 at 15:30 -0600, Richard Suberg wrote:
> > On 2/17/2011 12:33 PM, Daniel Givens wrote:
> > > On Feb 16, 2011, at 4:45 PM, Richard Suberg wrote:
> > >
> > >> My questions are:
> > >> 1. Does Ubuntu disassemle the raid assembly to deal strictly with the
> > >> physical disks and how can I use the RAID setup under Ubuntu?

In a true hardware RAID, the OS cannot directly address any underlying disk

> > >> 2. I was going to use gparted to copy the partition from the old RAID
> > >> to the new RAID when I noticed this "glitch." If I can't use the HW
> > >> RAID setup, if I get the partition copied to the physical sdc, can I
> > >> dd sdc to sdd and reassemble the RAID? I am doing RAID 0 (mirror).

Without a great deal more info here, I would suggest the following:


   - RAIDset 1 is a Mirror (RAID1) with 450GB drives and RAIDSet 2 is a
   Mirror (RAID1) with 2TB drives.
   - RAIDset 1 contains your data and RAIDset 2 is empty (no data to
   - Use windows native functionality
   - Not booting from either of the the RAIDsets

If you just want to result in a grown RAIDset (450G -> 2T), then the easiest
way to do this is:

   1. Simply "fail" a spindle of the RAIDset and add a larger replacement
   spindle (ie replace a 450G with 2T spindle)
   2. Let the mirror resync with the asymetrical disk config
   3. "Fail"/replace the remaining smaller disk (ie replace other 450G with
   last 2T spindle)
   4. Let the mirror resync with new, larger disk config
   5. Expand the RAIDset to fill disk.

This can be done without downtime in most cases (I have hot-swap shelves, so
I literally did this over the last week and will regale those interested
with the story once I am completely done with the migration)

Now if you are in a bootable RAID scenario, this is a different case, and
depends on the implementation as to how easy this will be, but is doable.

> > >> 3. Any other suggestions to copy all this data? 450 GB partition ->
> > >> 2TB partition, 500 GB data. Need to preserve permissions, and this is
> > >> an NTFS file system, stuck in windows.

Note above.  The method outlined is simple a swap-n-grow process that is
wall-clock time intensive, but not man-power intensive.  The other way to do
this is with `robocopy /datsou` or similar file-level copy tool (ie xxcopy
or SFFS).  In this case, you would have a dive letter that is the old raid
(ie O:\) and a drive letter that is the new RAID (ie N:\) and you would do
something like:

`robocopy /copyall O:\ N:\` .  You may need to add other switches if you
want logging and different retry/wait times, restartable mode, etc

> > > So it sounds like it's software RAID. The Windows drivers know how to
> > present it as a single volume, where the Linux does not. Not 100% sure
> > on this, but you're probably going to be stuck with managing the data
> > completely from Windows.

Yep, the windows drivers remove visibility to the component spindles and
only allow the raid volume to be visible (Except in a parity RAID situation,
where the parity calculations might be assisted by hardware, but most times
are CPU run).  IN the case of a mirror, the IO is simply split and applied
to all the component devices atomically.

Let me know if further discussion is required, and would certainly dive

More information about the SATLUG mailing list