[Adaptec 2610SA] Add HDD to existing RAID 5 array

Greetings,

is there a way to add a disk to a RAID 5 array (4x 500GB) in order to
expand capacity? The only option I can manage to find in Adaptec's BIOS is
adding a hot spare, but no sign of expanding array.

I use Debian Lenny - is there any CLI tool for Adaptec SATA RAID
management?

TIA!

--
Everything will be okay, in the end.
If it's not okay - it's not the end!
§ http://math2.ath.cx §

Bubba wrote:
Greetings,

is there a way to add a disk to a RAID 5 array (4x 500GB) in order to
expand capacity? The only option I can manage to find in Adaptec's BIOS is
adding a hot spare, but no sign of expanding array.

I use Debian Lenny - is there any CLI tool for Adaptec SATA RAID
management?

TIA!


No. You must backup the current array, then create a new array,
then restore the backed-up data to the new array.
--
Cheers, Bob

Bob Willard's log on stardate 16 ruj 2009

No. You must backup the current array, then create a new array,
then restore the backed-up data to the new array.

This is a joke based on me missing something crucial in the whole story or
you are actually telling me that #$%! Adaptec has no support for on-line
array expansion on this controller?

--
Everything will be okay, in the end.
If it's not okay - it's not the end!
§ http://math2.ath.cx §

Bubba wrote:
Bob Willard's log on stardate 16 ruj 2009

No. You must backup the current array, then create a new array,
then restore the backed-up data to the new array.

This is a joke based on me missing something crucial in the whole story or
you are actually telling me that #$%! Adaptec has no support for on-line
array expansion on this controller?


It is not Adaptec, it is the nature of RAID5. Draw a picture of how the
data and parity blocks are spread over the HDs in the RAIDset, and how
you would go about adding another HD to an existing array. While an
incremental expansion could be done, if the existing array has enough
unused space, it is far faster and safer to just do the full monte:
backup/recreate/restore.
--
Cheers, Bob

On or about 16 Sep 2009 17:26:01 GMT did Bubba
dribble thusly:

Greetings,

is there a way to add a disk to a RAID 5 array (4x 500GB) in order to
expand capacity? The only option I can manage to find in Adaptec's BIOS is
adding a hot spare, but no sign of expanding array.

I use Debian Lenny - is there any CLI tool for Adaptec SATA RAID
management?

http://preview.tinyurl.com/lsfe5s

I despise URL shorteners, but that one was just too hideous to post directly.

The 2610SA is an OEM-only board made by Adaptec for Dell and HP, so if the
above doesn't help, try poking around their sites.

In message Bob Willard
was claimed to have wrote:

It is not Adaptec, it is the nature of RAID5. Draw a picture of how the
data and parity blocks are spread over the HDs in the RAIDset, and how
you would go about adding another HD to an existing array.

That's fairly trivial.

First, take a look at the map as it exists now, and the preferred
result.

Start off by moving any existing blocks to the new drive as needed. This
frees up gaps on the existing drives, now look for what data should go
to each of those empty blocks. Rinse, repeat.

While an
incremental expansion could be done, if the existing array has enough
unused space,

No unused space is needed, luckily by definition we have a new drive
available to start the process, the new drive offers enough free space.

it is far faster and safer to just do the full monte:
backup/recreate/restore.

It will always take longer to do a full backup/recreate/restore process,
and may end up being riskier to your data during the process.

In an ideal situation, your suggestion requires a read of the entire
array, write to another place, then the new array configuration can be
initialized (a full write cycle to the entire drive). At this point you
need to read all of the data again and write it to the RAID-5 array, but
as you're no doubt aware, writing to a RAID-5 array isn't just a single
write, but rather, it's a minimum of two reads and one writes and more
likely is two reads and two writes with some math in the middle there
(unless your data happens to match the results of your array
initialization)

Compare this to reorganizing an existing array, where the process
requires every sector to be read once and written once at best, or at
worst and read once and written twice (allowing for data to be
temporarily stored elsewhere during sector reorganizations, a process
which is entirely safe if properly journaled)

That being said, a live migration is a significantly more complex
process from the controller's point of view, so it's less likely that
inexpensive controllers can implement live migrations.

Bob Willard wrote:
Bubba wrote:
Bob Willard's log on stardate 16 ruj 2009

No. You must backup the current array, then create a new array,
then restore the backed-up data to the new array.

This is a joke based on me missing something crucial in the whole
story or you are actually telling me that #$%! Adaptec has no support
for on-line array expansion on this controller?


It is not Adaptec, it is the nature of RAID5. Draw a picture of how the
data and parity blocks are spread over the HDs in the RAIDset, and how
you would go about adding another HD to an existing array. While an
incremental expansion could be done, if the existing array has enough
unused space, it is far faster and safer to just do the full monte:
backup/recreate/restore.

I have no idea about Adaptec's controller, but with Linux md software
raid 5 there is no problem adding or removing drives. It can also
convert a raid 5 to a raid 6 when you add an extra disk. This won't
really help the OP if he is stuck with a proprietary controller and its
limits (if any - as I say, I don't know the controller or its
capabilities), but there is certainly nothing in raid 5 that makes
changing the number of devices an impossible task.

David Brown wrote:
Bob Willard wrote:
Bubba wrote:
Bob Willard's log on stardate 16 ruj 2009

No. You must backup the current array, then create a new array,
then restore the backed-up data to the new array.

This is a joke based on me missing something crucial in the whole
story or you are actually telling me that #$%! Adaptec has no support
for on-line array expansion on this controller?


It is not Adaptec, it is the nature of RAID5. Draw a picture of how the
data and parity blocks are spread over the HDs in the RAIDset, and how
you would go about adding another HD to an existing array. While an
incremental expansion could be done, if the existing array has enough
unused space, it is far faster and safer to just do the full monte:
backup/recreate/restore.

I have no idea about Adaptec's controller, but with Linux md software
raid 5 there is no problem adding or removing drives. It can also
convert a raid 5 to a raid 6 when you add an extra disk. This won't
really help the OP if he is stuck with a proprietary controller and its
limits (if any - as I say, I don't know the controller or its
capabilities), but there is certainly nothing in raid 5 that makes
changing the number of devices an impossible task.

Converting from RAID5 to RAID6 is trivial, since the added HD is not
used -- just a hot spare. Failover from RAID6 to RAID5 is pretty
messy, but growing from RAID5 to RAID6 is simple.
--
Cheers, Bob

DevilsPGD wrote:
In message Bob Willard
was claimed to have wrote:

It is not Adaptec, it is the nature of RAID5. Draw a picture of how the
data and parity blocks are spread over the HDs in the RAIDset, and how
you would go about adding another HD to an existing array.

That's fairly trivial.

First, take a look at the map as it exists now, and the preferred
result.

Start off by moving any existing blocks to the new drive as needed. This
frees up gaps on the existing drives, now look for what data should go
to each of those empty blocks. Rinse, repeat.

While an
incremental expansion could be done, if the existing array has enough
unused space,

No unused space is needed, luckily by definition we have a new drive
available to start the process, the new drive offers enough free space.

it is far faster and safer to just do the full monte:
backup/recreate/restore.

It will always take longer to do a full backup/recreate/restore process,
and may end up being riskier to your data during the process.

In an ideal situation, your suggestion requires a read of the entire
array, write to another place, then the new array configuration can be
initialized (a full write cycle to the entire drive). At this point you
need to read all of the data again and write it to the RAID-5 array, but
as you're no doubt aware, writing to a RAID-5 array isn't just a single
write, but rather, it's a minimum of two reads and one writes and more
likely is two reads and two writes with some math in the middle there
(unless your data happens to match the results of your array
initialization)

Compare this to reorganizing an existing array, where the process
requires every sector to be read once and written once at best, or at
worst and read once and written twice (allowing for data to be
temporarily stored elsewhere during sector reorganizations, a process
which is entirely safe if properly journaled)

That being said, a live migration is a significantly more complex
process from the controller's point of view, so it's less likely that
inexpensive controllers can implement live migrations.

Huh. I hadn't even considered adding a HD to an offline array; clearly
that is simple. And the case of a controller with enough ports to
have the old (N HD) array and the new (N+1 HD) array concurrently
connected is also relatively simple.

The only interesting (to me) case is adding a HD to a RAIDset which
is being used -- with files that are active and open. And doing that
cleanly and safely, without the cooperation of the filesystem, is a
challenge: rather likely to result in substantial loss of performance
during the addition and/or a badly fragmented array. Even if the
controller claimed to be able to dynamically add HDs to an active
RAID5/6 RAIDset, I doubt if I'd trust it without backups.
--
Cheers, Bob

Bob Willard wrote:
David Brown wrote:
Bob Willard wrote:
Bubba wrote:
Bob Willard's log on stardate 16 ruj 2009

No. You must backup the current array, then create a new array,
then restore the backed-up data to the new array.

This is a joke based on me missing something crucial in the whole
story or you are actually telling me that #$%! Adaptec has no
support for on-line array expansion on this controller?


It is not Adaptec, it is the nature of RAID5. Draw a picture of how the
data and parity blocks are spread over the HDs in the RAIDset, and how
you would go about adding another HD to an existing array. While an
incremental expansion could be done, if the existing array has enough
unused space, it is far faster and safer to just do the full monte:
backup/recreate/restore.

I have no idea about Adaptec's controller, but with Linux md software
raid 5 there is no problem adding or removing drives. It can also
convert a raid 5 to a raid 6 when you add an extra disk. This won't
really help the OP if he is stuck with a proprietary controller and
its limits (if any - as I say, I don't know the controller or its
capabilities), but there is certainly nothing in raid 5 that makes
changing the number of devices an impossible task.

Converting from RAID5 to RAID6 is trivial, since the added HD is not
used -- just a hot spare. Failover from RAID6 to RAID5 is pretty
messy, but growing from RAID5 to RAID6 is simple.

Either I'm missing something here, or /you/ are missing something.

Raid5 to Raid6 is far from trivial, because it is not a hot spare.
Raid6 has two parities per stripe rather than one, so you need to go
through the entire array calculating the second parity. That in itself
is pretty easy if you are happy storing the Q parity on the new disk,
but re-doing the stripe layout to standard raid 6 will involve
re-writing everything on the disk. Converting raid6 to raid 5 is sort
of the reverse - change the raid 6 standard layout to putting Q on one
disk, then removing the Q disk.

Have a look at this post from the Linux md developer:

http://neil.brown.name/blog/20090817000931