Is it safe to move spanned drives between SATA ports?

With Windows 7 Home 64-bit this worked flawlessly and entirely automatically for me.

I tried this with a spanned volume of 9TB (3x2TB + 1x3TB) where by mistake I had connected the 3TB drive to a JMicron 363 SATA-port and the rest were connected to the integrated nVidia nvraid ports. The use of the JMicron port worked reasonably fine in IDE-mode, but when I tried to configure it in AHCI-mode it acted randomly giving varying write speeds between 18MB/s to 67MB/s whereas the same drive now connected to the nForce SATA-port clocks in a steady 80MB/s both read and write. (SATA-300).

Procedure:
1. Update all SATA controller drivers to the newest version just in case. My Computer -> Manage -> Device Manager -> Storage Devices -> <controller> -> Update Driver -> Update Automatically
2. Reboot computer to verify that the drivers work properly.
3. Shutdown computer, switch power supply off or unplug from wall before detaching the SATA cables
4. Move SATA cable to desired new SATA-port on the motherboard/SATA-controller card.
5. Replug the power supply. Start computer.
6. Login to Windows normally, wait for automatic device driver installation to finish and when prompted, reboot. (Device driver association is per port, but clearly volume information is writen on each disk in the spanning group and is not dependent on SATA-port numbers)
7. After reboot your are done. Have Fun!

HOWTO: Using Larger Than 2TB Drives on Areca ARC-1220 Raid Controller

I got my hands on a Western Digital 3TB Caviar Green drive (WD30EZRS) and promptly put it through some tests on my home server.

The Areca ARC-1220 raid controller detects the drive fine as a 3TB drive with the newest firmware (Firmware v1.49, Boot ROM v1.49).

After booting up my Ubuntu 11.10 Server 64-bit (oneiric) I tried to format & mount the drive in my usual fashion with fdisk /dev/mapper/areca-lv1 and mke2fs /dev/mapper/areca-lv1 and ended up with a 2TB partition. Fail.

So I Googled a bit and found this excellent article on making GPT partition tables for >2TB drives. I will reproduce the steps required to get the partition up and running here for convenience. Substitute /dev/sdb with your raid controller device node like /dev/mapper/areca-lv1 in my case:

To create a partition start GNU parted as follows:

# parted /dev/sdb

Output:

GNU Parted 2.3
Using /dev/sdb

Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted)

Creates a new GPT disklabel i.e. partition table:

(parted) mklabel gpt

Sample outputs:

Warning: The existing disk label on /dev/sdb will be destroyed and all data on this disk will be lost. Do you want to continue?
Yes/No? yes
(parted)

Next, set the default unit to TB, enter:

(parted) unit TB

To create a 3TB partition size, enter:

(parted) mkpart primary 0 0

OR

(parted) mkpart primary 0.00TB 3.00TB

To print the current partitions, enter:

(parted) print

Sample outputs:

Model: ATA ST33000651AS (scsi)
Disk /dev/sdb: 3.00TB
Sector size (logical/physical): 512B/512B
Partition Table: gpt

Number Start End Size File system Name Flags
 1 0.00TB 3.00TB 3.00TB ext4 primary

Quit and save the changes, enter:

(parted) quit

Sample outputs:

Information: You may need to update /etc/fstab.
Use the mkfs.ext3 or mkfs.ext4 command to format the file system, enter:

# mkfs.ext3 /dev/sdb1

OR

# mkfs.ext4 /dev/sdb1

Sample outputs:

mkfs.ext4 /dev/sdb1

mke2fs 1.41.12 (17-May-2010)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
183148544 inodes, 732566272 blocks
36628313 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=4294967296
22357 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group

Superblock backups stored on blocks:

32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968, 102400000, 214990848, 512000000, 550731776, 644972544

Writing inode tables: done
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done
This filesystem will be automatically checked every 31 mounts or
180 days, whichever comes first. Use tune2fs -c or -i to override.

Type the following commands to mount /dev/sdb1, enter:

# mkdir /data
# mount /dev/sdb1 /data
# df -H

Sample outputs:

Filesystem Size Used Avail Use% Mounted on
/dev/sdc1 16G 819M 14G 6% /
tmpfs 1.6G 0 1.6G 0% /lib/init/rw
udev 1.6G 123k 1.6G 1% /dev
tmpfs 1.6G 0 1.6G 0% /dev/shm
/dev/sdb1 3.0T 211M 2.9T 1% /data

Make sure you replace /dev/sdb1 with actual RAID or Disk name or Block Ethernet device such as /dev/etherd/e0.0. Do not forget to update /etc/fstab, if necessary. Also note that booting from a GPT volume requires support in your BIOS / firmware. This is not supported on non-EFI platforms. I suggest you boot server from another disk such as IDE / SATA / SSD disk and store data on /data.

HOWTO: Add capasity to an existing hardware raid-5 set on a Areca ARC1220 8-channel PCIe raid-array running Ubuntu 7.10 64bit, LVM2 and ext3?

Preparation

First order of business is, as usual, BACKUP ALL DATA on the array.

After this you might want to insert the new disk into the array either with a hot-swap carrier (like in my case a IcyDock MB455SPF) or incase you are running the array with permanently attached drives by shutting down the computer and adding another drive to the controller.

Begin Hardware Volume configuration

The raid controller will begin automatic detection of the new drive instantly after insertation (or after boot if not hotswap). The new drive will be marked as unused free space / unallocated.

At this point you should be in a running instance of Ubuntu. Fire up the Areca Linux Control HTTP-service 

bash #> archttp64

in my case since I'm running Ubuntu 7.10 64-bit Alternative install.

Connect to the WebManagement interface at http://localhost:81 if you have the management daemon running with defaults.

Default values for console authentication are admin:0000

Once you have successfully authenticated to the console check the status of the array from the front page. You should see the new drive(s) as free space and unused.

Now begin the array expansion by selecting

RaidSet Functions -> Expand Raid Set

Select the RaidSet you want to expand and click the submit button -> select the free volumes you want to add to the RaidSet and check the confirmation tick-box and click on submit.

Wait for the RaidSet to rebuild. This will take a long time depending on the size of your array. With a 1TB expansion the rebuild time is around 24h.

After the RaidSet Expansion is complete (you'll see progress from the WebAdmin Console in the Volume State field) you will need to add the new space to the current VolumeSet by selecting

VolumeSet Functions -> Modify Volume Set

and entering the new volume size into the size field and if you are expanding the array over 2TB you might need to set the 2TB limit circumvention to off depending on your OS and filesystem.

Wait for the VolumeSet expansion to complete. This will take about 3-4h for 1TB expansion.

LVM2 and ext3 resizing

You may resize your LVM2 volumes online with atleast LVM v2.02.26 shipping with Ubuntu 7.10.

Issue the command

bash #> pvdisplay

to view current volume information. Then you issue the command

bash #> pvresize /dev/sda

This will happen almost instantly.

At this point you will want to reboot the server to update the kernels view of the logical volumes.

Now you may check the new size of the physical volume by issuing the command

bash #> pvdisplay

again. Write down the available PE-count (Physical Extents) of the resized volume. This information will be needed in the next step.

Next we will expand your logical volumes to max available size by issuing the command

bash #> lvresize -l (insert Total PE-number) /dev/areca/volume-name

Wait for volume resizing. This will take abt. 3h per TB.

After stopping of all networking services that use the volume and unmounting the volume

bash #> umount /dev/areca/volume-name

(not strictly nescessary since resize2fs supports nowadays online resizing) you may begin priming the system for the expansion of the ext3 filesystem by issuing the command

bash #> e2fsck -vtf /dev/areca/volume-name

This will run a filesystem check on the current filesystem and reset all check-bits so that the resizing utility will run. This will take about an hour per terabyte of data in the array. e2fsck is very bad at telling what it's doing so don't panic if it seems to hang.

Resize the ext3 filesystem by

bash #> resize2fs -p /dev/areca/volume-name

This will take another 30 min - 1h.

After the resize successfully completes reboot the server.

Same as above in a flow chart format