RE: Concatenation with redundancy

RE: Concatenation with redundancy

[Bob Hillegas]

How about an option to create a one-time RAID1 mirror on top of existing 
raid structure? What it really is, is a backup. Install necessary drives, 
trigger mirroring, remove drives, and array goes back to previous state 
without additional mirror.

Beats backing up multi-tera-bytes to floppies. :-)

BobH

-----Original Message-----
From:	Tony Mantler [SMTP:nicoya@ubb.ca]
Sent:	Tuesday, September 07, 2004 11:53 AM
To:	linux-raid@vger.kernel.org
Subject:	Concatenation with redundancy

Hello,

Recently I've seen a growing trend in creating very ad-hoc storage
arrays for storing large quantities of media files (videos, music,
etc). These arrays are usually initially created with a small number of
concatenated drives, say 2 or 3, but over time can easily grow to span
6 or 8 drives as personal budgets allow.

Obviously as time goes by the exposure to a single drive failure taking
down the whole filesystem increases considerably, and I've seen this
happen a number of times. Due to the size (frequently 1-2tb) and nature
of data on the array, backup is usually impractical.

It would seem that the current options for combining redundancy with
flexible expansion capability leave a little to be desired. RAID 10
presents far too much wasted space for this type of application, and
RAID 50 offers much less flexibility than is desired, and is still too
inefficient for the number of drives in question.

Thus the idea came to me for creating a somewhat new RAID level, which
would be a concatenation with dedicated parity. Call it RAID 4C maybe,
as in "RAID 4, but concatenated rather than striped".

Thus, the data would appear as thus:

drive 1   drive 2   .. parity drive
block 1 ~ block N+1 .. = parity 1
block 2 ~ block N+2 .. = parity 2
..
block N ~ block N+M .. = parity N

This would allow for inserting new drives without mangling the block
order, thus preserving the data on the array. Ideally it would also be
possible to create a heterogeneous array by ensuring that the parity
drive was equal to or larger than the largest data drive, and assuming
zeroed blocks for all non-present sectors.


So, am I smoking crack here? Does anyone think this would be worth
implementing? Has this already been implemented and I just haven't seen
it?


Cheers - Tony 'Nicoya' Mantler :)

--
Tony 'Nicoya' Mantler -- Master of Code-fu -- nicoya@ubb.ca
--  http://nicoya.feline.pp.se/  --  http://www.ubb.ca/  --

-
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Concatenation with redundancy

[Tony Mantler]

On 7-Sep-04, at 12:36 PM, Bob Hillegas wrote:

> How about an option to create a one-time RAID1 mirror on top of 
> existing
> raid structure? What it really is, is a backup. Install necessary 
> drives,
> trigger mirroring, remove drives, and array goes back to previous state
> without additional mirror.
>
> Beats backing up multi-tera-bytes to floppies. :-)

True, but that's not *quite* what I'm looking for. ;)


Cheers - Tony 'Nicoya' Mantler :)

--
Tony 'Nicoya' Mantler -- Master of Code-fu -- nicoya@ubb.ca
--  http://nicoya.feline.pp.se/  --  http://www.ubb.ca/  --

Re: Concatenation with redundancy

[berk walker]

I think that this would be the answer to many private ops' motivation to 
RAID.  With the newer motherboards, unplugging the drive power and a 
CMOS tweak, the destination drive would be on a completely different 
life-cycle.  Of course, the reboot would be a "bad thing" in a 
"production" system.

b-

Bob Hillegas wrote:

>How about an option to create a one-time RAID1 mirror on top of existing 
>raid structure? What it really is, is a backup. Install necessary drives, 
>trigger mirroring, remove drives, and array goes back to previous state 
>without additional mirror.
>
>Beats backing up multi-tera-bytes to floppies. :-)
>
>BobH
>
>-----Original Message-----
>From:	Tony Mantler [SMTP:nicoya@ubb.ca]
>Sent:	Tuesday, September 07, 2004 11:53 AM
>To:	linux-raid@vger.kernel.org
>Subject:	Concatenation with redundancy
>
>Hello,
>
>Recently I've seen a growing trend in creating very ad-hoc storage
>arrays for storing large quantities of media files (videos, music,
>etc). These arrays are usually initially created with a small number of
>concatenated drives, say 2 or 3, but over time can easily grow to span
>6 or 8 drives as personal budgets allow.
>
>Obviously as time goes by the exposure to a single drive failure taking
>down the whole filesystem increases considerably, and I've seen this
>happen a number of times. Due to the size (frequently 1-2tb) and nature
>of data on the array, backup is usually impractical.
>
>It would seem that the current options for combining redundancy with
>flexible expansion capability leave a little to be desired. RAID 10
>presents far too much wasted space for this type of application, and
>RAID 50 offers much less flexibility than is desired, and is still too
>inefficient for the number of drives in question.
>
>Thus the idea came to me for creating a somewhat new RAID level, which
>would be a concatenation with dedicated parity. Call it RAID 4C maybe,
>as in "RAID 4, but concatenated rather than striped".
>
>Thus, the data would appear as thus:
>
>drive 1   drive 2   .. parity drive
>block 1 ~ block N+1 .. = parity 1
>block 2 ~ block N+2 .. = parity 2
>..
>block N ~ block N+M .. = parity N
>
>This would allow for inserting new drives without mangling the block
>order, thus preserving the data on the array. Ideally it would also be
>possible to create a heterogeneous array by ensuring that the parity
>drive was equal to or larger than the largest data drive, and assuming
>zeroed blocks for all non-present sectors.
>
>
>So, am I smoking crack here? Does anyone think this would be worth
>implementing? Has this already been implemented and I just haven't seen
>it?
>
>
>Cheers - Tony 'Nicoya' Mantler :)
>
>--
>Tony 'Nicoya' Mantler -- Master of Code-fu -- nicoya@ubb.ca
>--  http://nicoya.feline.pp.se/  --  http://www.ubb.ca/  --
>
>-
>To unsubscribe from this list: send the line "unsubscribe linux-raid" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>
>-
>To unsubscribe from this list: send the line "unsubscribe linux-raid" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>  
>

Concatenation with redundancy

[Tony Mantler]

Hello,

Recently I've seen a growing trend in creating very ad-hoc storage 
arrays for storing large quantities of media files (videos, music, 
etc). These arrays are usually initially created with a small number of 
concatenated drives, say 2 or 3, but over time can easily grow to span 
6 or 8 drives as personal budgets allow.

Obviously as time goes by the exposure to a single drive failure taking 
down the whole filesystem increases considerably, and I've seen this 
happen a number of times. Due to the size (frequently 1-2tb) and nature 
of data on the array, backup is usually impractical.

It would seem that the current options for combining redundancy with 
flexible expansion capability leave a little to be desired. RAID 10 
presents far too much wasted space for this type of application, and 
RAID 50 offers much less flexibility than is desired, and is still too 
inefficient for the number of drives in question.

Thus the idea came to me for creating a somewhat new RAID level, which 
would be a concatenation with dedicated parity. Call it RAID 4C maybe, 
as in "RAID 4, but concatenated rather than striped".

Thus, the data would appear as thus:

drive 1   drive 2   .. parity drive
block 1 ~ block N+1 .. = parity 1
block 2 ~ block N+2 .. = parity 2
..
block N ~ block N+M .. = parity N

This would allow for inserting new drives without mangling the block 
order, thus preserving the data on the array. Ideally it would also be 
possible to create a heterogeneous array by ensuring that the parity 
drive was equal to or larger than the largest data drive, and assuming 
zeroed blocks for all non-present sectors.


So, am I smoking crack here? Does anyone think this would be worth 
implementing? Has this already been implemented and I just haven't seen 
it?


Cheers - Tony 'Nicoya' Mantler :)

--
Tony 'Nicoya' Mantler -- Master of Code-fu -- nicoya@ubb.ca
--  http://nicoya.feline.pp.se/  --  http://www.ubb.ca/  --

RE: Concatenation with redundancy

[Guy]

I can see how this would be useful.
Being able to add disks over time, and of different sizes.
The parity disk would be the biggest.
Disks tend to get larger over time.  So, when you add a disk it will tend to
be larger than any of the others.  The current parity would be re-used to
extend the size, and the new disk would become the new parity.

What would happen when you replace a failed disk with a new larger disk?
Just waste the extra space?

The performance would not be too good.  Like raid5 on a real real bad day!

I don't like concatenated disks.  You can't balance the load on the drives.
I would never use this feature if it did exist.  But, some would love it I
bet.

Guy

-----Original Message-----
From: linux-raid-owner@vger.kernel.org
[mailto:linux-raid-owner@vger.kernel.org] On Behalf Of Tony Mantler
Sent: Tuesday, September 07, 2004 12:53 PM
To: linux-raid@vger.kernel.org
Subject: Concatenation with redundancy

Hello,

Recently I've seen a growing trend in creating very ad-hoc storage 
arrays for storing large quantities of media files (videos, music, 
etc). These arrays are usually initially created with a small number of 
concatenated drives, say 2 or 3, but over time can easily grow to span 
6 or 8 drives as personal budgets allow.

Obviously as time goes by the exposure to a single drive failure taking 
down the whole filesystem increases considerably, and I've seen this 
happen a number of times. Due to the size (frequently 1-2tb) and nature 
of data on the array, backup is usually impractical.

It would seem that the current options for combining redundancy with 
flexible expansion capability leave a little to be desired. RAID 10 
presents far too much wasted space for this type of application, and 
RAID 50 offers much less flexibility than is desired, and is still too 
inefficient for the number of drives in question.

Thus the idea came to me for creating a somewhat new RAID level, which 
would be a concatenation with dedicated parity. Call it RAID 4C maybe, 
as in "RAID 4, but concatenated rather than striped".

Thus, the data would appear as thus:

drive 1   drive 2   .. parity drive
block 1 ~ block N+1 .. = parity 1
block 2 ~ block N+2 .. = parity 2
..
block N ~ block N+M .. = parity N

This would allow for inserting new drives without mangling the block 
order, thus preserving the data on the array. Ideally it would also be 
possible to create a heterogeneous array by ensuring that the parity 
drive was equal to or larger than the largest data drive, and assuming 
zeroed blocks for all non-present sectors.


So, am I smoking crack here? Does anyone think this would be worth 
implementing? Has this already been implemented and I just haven't seen 
it?


Cheers - Tony 'Nicoya' Mantler :)

--
Tony 'Nicoya' Mantler -- Master of Code-fu -- nicoya@ubb.ca
--  http://nicoya.feline.pp.se/  --  http://www.ubb.ca/  --

-
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Concatenation with redundancy

[Tony Mantler]

On 7-Sep-04, at 2:09 PM, Guy wrote:

> I can see how this would be useful.
> Being able to add disks over time, and of different sizes.
> The parity disk would be the biggest.
> Disks tend to get larger over time.  So, when you add a disk it will 
> tend to
> be larger than any of the others.  The current parity would be re-used 
> to
> extend the size, and the new disk would become the new parity.

Exactly.


> What would happen when you replace a failed disk with a new larger 
> disk?
> Just waste the extra space?

Probably, but it's easy to find small disks on eBay and the like. It's 
no worse than replacing a failed drive in a homogeneous array.


> The performance would not be too good.  Like raid5 on a real real bad 
> day!

That's true. However, writes would be fairly rare for the application 
of a media library, with most of the accesses being read-only.


> I don't like concatenated disks.  You can't balance the load on the 
> drives.
> I would never use this feature if it did exist.  But, some would love 
> it I
> bet.

It's much easier to add space to a concatenated set though, and single 
drive performance is easily sufficient for the media library 
application.


Cheers - Tony 'Nicoya' Mantler :)

--
Tony 'Nicoya' Mantler -- Master of Code-fu -- nicoya@ubb.ca
--  http://nicoya.feline.pp.se/  --  http://www.ubb.ca/  --

Re: Concatenation with redundancy

[maarten]

On Tuesday 07 September 2004 18:52, Tony Mantler wrote:
> Hello,
>
> Recently I've seen a growing trend in creating very ad-hoc storage
> arrays for storing large quantities of media files (videos, music,
> etc). These arrays are usually initially created with a small number of
> concatenated drives, say 2 or 3, but over time can easily grow to span
> 6 or 8 drives as personal budgets allow.
>
> Obviously as time goes by the exposure to a single drive failure taking
> down the whole filesystem increases considerably, and I've seen this
> happen a number of times. Due to the size (frequently 1-2tb) and nature
> of data on the array, backup is usually impractical.

I know (and share) that feeling.  However, as has been said so often, raid is 
no substitute for backups.  Because apart from drive failure there are much 
much more dangers to killing your files, and they are in part even more real 
dangers as well; think about theft, viruses, user-error, fire and lightning 
strikes.  (And a whole bunch more, if you happen to live in Florida...) 

> It would seem that the current options for combining redundancy with
> flexible expansion capability leave a little to be desired. RAID 10
> presents far too much wasted space for this type of application, and
> RAID 50 offers much less flexibility than is desired, and is still too
> inefficient for the number of drives in question.
>
> Thus the idea came to me for creating a somewhat new RAID level, which
> would be a concatenation with dedicated parity. Call it RAID 4C maybe,
> as in "RAID 4, but concatenated rather than striped".
>
> Thus, the data would appear as thus:
>
> drive 1   drive 2   .. parity drive
> block 1 ~ block N+1 .. = parity 1
> block 2 ~ block N+2 .. = parity 2
> ..
> block N ~ block N+M .. = parity N

Don't know if it exists or not, I'm not fully versed on the different raid 
levels.  But wouldn't it be moke akin to a linear array + parity ?  As I 
understand you, all of the 'first' data resides on disk1 until that is full 
and then further data goes on the next drive, etc.
You lose all performance benefits that other raid levels offer this way of 
course, but that might be a drawback that one can live with, depending on the 
scenario you use it for...  
I think it's a nice idea.  Performance-wise it's probably a real bad idea 
(you'll usually use only 1 of the drives, and the parity drive will be hit 
real hard since it is read & written at every access). But, who knows ? 

Maarten

> This would allow for inserting new drives without mangling the block
> order, thus preserving the data on the array. Ideally it would also be
> possible to create a heterogeneous array by ensuring that the parity
> drive was equal to or larger than the largest data drive, and assuming
> zeroed blocks for all non-present sectors.
>
>
> So, am I smoking crack here? Does anyone think this would be worth
> implementing? Has this already been implemented and I just haven't seen
> it?
>
>
> Cheers - Tony 'Nicoya' Mantler :)
>
> --
> Tony 'Nicoya' Mantler -- Master of Code-fu -- nicoya@ubb.ca
> --  http://nicoya.feline.pp.se/  --  http://www.ubb.ca/  --
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
When I answered where I wanted to go today, they just hung up -- Unknown

Re: Concatenation with redundancy

[Neil Brown]

On Tuesday September 7, nicoya@ubb.ca wrote:
> Hello,
> 
> Recently I've seen a growing trend in creating very ad-hoc storage 
> arrays for storing large quantities of media files (videos, music, 
> etc). These arrays are usually initially created with a small number of 
> concatenated drives, say 2 or 3, but over time can easily grow to span 
> 6 or 8 drives as personal budgets allow.
...
> 
> 
> So, am I smoking crack here? Does anyone think this would be worth 
> implementing? Has this already been implemented and I just haven't seen 
> it?

I don't know if it has been implemented, though it's not known on
Linux.
I am planning to do something like that eventually, but not until I
have written a filesystem that would make good use of it (it's
planned, but work is slow).

I hadn't thought of allowing drives to be different sizes.  It would
complicate some aspects, but it could be made to work... I guess.

NeilBrown