headers
Robin Bowes | 1 Oct 2005 18:10
Favicon

Re: Convert RAID5 to RAID6<--correction?

I did of course mean RAID5 to RAID*6*.

Subject corrected.

R.

Robin Bowes said the following on 30/09/2005 17:16:
> OK,
> 
> Based on some comments I've received following my previous post about 
> large storage arrays, and having read around a bit, I think my 6-disk 
> 1TB array would be better as RAID6 rather than RAID5 plus hot spare.
> 
> Is it possible to convert from RAID5 to RAID6? Or would I have to dump 
> the whole array to tape, trash it, create the RAID6 array and restore 
> from tape?
> 
> Thanks,
> 
> R.

--

-- 
http://robinbowes.com

If a man speaks in a forest,
and his wife's not there,
is he still wrong?

-
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
(Continue reading)

Permalink | Reply | 0 comments |
headers
Gordon Mohr (@ Bitzi | 1 Oct 2005 23:21

madadm man page ambiguities: '--size' units, superblock affordance

My 'mdadm' (v1.6.0) man page includes:

#       -z, --size=
#              Amount  (in  Kibibytes)  of  space  to  use  from each drive in
#              RAID1/4/5/6.  This must be a multiple of the  chunk  size,  and
#              must leave about 128Kb of space at the end of the drive for the
#              RAID superblock.  If this is not specified (as it  normally  is
#              not) the smallest drive (or partition) sets the size, though if
#              there is a variance among the drives  of  greater  than  1%,  a
#              warning is issued.

There are several problems when trying to interpret the phrase "This must be a
multiple of the chunk  size,  and must leave about 128Kb of space at the end of
the drive for the RAID superblock."

(1) Someone resizing an array may not know the chunk size, and it's unclear
if assuming the default of 64 is OK, or dangerous. (My experiments show that
'mdadm' will accept a size value that is not a multiple of 64, and will update
the array size as shown by --detail to this non-multiple size, at least for
RAID1. Does this risk disaster?)

(2) "Kb" is technically the abbrieviation of "kilobits", not "kibibytes". I'm
assuming "128Kb" means "128 kibibytes" from the preceding context. I suggest
avoiding the abbrieviation entirely to avoid confusion.

(3) To "leave" space is ambiguous in what it means for the value specified.
Should the we take the amount of space needed for our filesystem and add 128K
to get the 'size' value to specify? Or specify exactly what's needed for
the filesystem, and be aware that RAID will actually use 128K more on
the consitutent devices than what was specified? (I *think* the second is
(Continue reading)

Permalink | Reply | 2 comments |
headers
Christopher Smith | 2 Oct 2005 06:36

Re: Best way to achieve large, expandable, cheap storage?

Robin Bowes wrote:
> Hi,
> 
> I have a business opportunity which would involve a large amount of 
> storage, possibly growing to 10TB in the first year, possibly more. This 
> would be to store media files - probably mainly .flac or .mp3 files.

Here's what I do (bear in mind this is for a home setup, so the data 
volumes aren't as large and I'd expand in smaller amounts to you - but 
the principle is the same).

I use a combination of Linux's software RAID + LVM for a flexible, 
expandable data store.  I buy disks in sets of four, with a four-port 
disk controller and a 4-drive, cooled chassis of some sort (lately, the 
Coolermaster 4-in-3 part).

I RAID5 the drives together and glue multiple sets of 4 drives together 
into a single usable chunk using LVM.

Over the last ~5 years, this has allowed me to move from/to the 
following disk configurations:

4x40GB -> 4x40GB + 4x120GB -> 4x40GB + 4x120GB + 4x250GB -> 4x120GB + 
4x250GB -> 4x250GB + 4x250GB.

In the next couple of months I plan to add another 4x300GB "drive set" 
to expand further.  I add drives about once a year.  I remove drives 
either because I run out of physical room in the machine, or to re-use 
them in other machines (eg: the 4x120GB drives are now scratch space on 
my workstation, the 4x40GB drives went into machines I built for
(Continue reading)

Permalink | Reply | 11 comments |
headers
Tyler | 2 Oct 2005 09:09

Re: Best way to achieve large, expandable, cheap storage?

Christopher Smith wrote:

> Robin Bowes wrote:
>
>> Hi,
>>
>> I have a business opportunity which would involve a large amount of 
>> storage, possibly growing to 10TB in the first year, possibly more. 
>> This would be to store media files - probably mainly .flac or .mp3 
>> files.
>
>
> Here's what I do (bear in mind this is for a home setup, so the data 
> volumes aren't as large and I'd expand in smaller amounts to you - but 
> the principle is the same).
>
> I use a combination of Linux's software RAID + LVM for a flexible, 
> expandable data store.  I buy disks in sets of four, with a four-port 
> disk controller and a 4-drive, cooled chassis of some sort (lately, 
> the Coolermaster 4-in-3 part).
>
> I RAID5 the drives together and glue multiple sets of 4 drives 
> together into a single usable chunk using LVM.
>
> Over the last ~5 years, this has allowed me to move from/to the 
> following disk configurations:
>
> 4x40GB -> 4x40GB + 4x120GB -> 4x40GB + 4x120GB + 4x250GB -> 4x120GB + 
> 4x250GB -> 4x250GB + 4x250GB.
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Hank Barta | 2 Oct 2005 17:10
Picon

non-fresh drive?

I have a 5 disk raid that is currently using only 4 disks. On startup,
it rejects an apparently good drive with the message that it is
non-fresh. I don;t understand what non-fresh means nor how to resolve
this.

I start the raid using the command:
oak:~# mdadm -A /dev/md0 -f /dev/sd[abcd]1 /dev/hd[eg]1
mdadm: /dev/md0 has been started with 4 drives (out of 5).

and I see:
oak:~# cat /proc/mdstat
Personalities : [raid5]
md0 : active raid5 sdb1[1] hde1[4] sdd1[3] sdc1[2]
      781433344 blocks level 5, 32k chunk, algorithm 2 [5/4] [_UUUU]

unused devices: <none>

(It does not start automatically and at the moment, /dev/hdg1 is not
installed, but at the time that /dev/hdg1 failed, this command worked
and had all 5 drives working.)

dmesg reports:
md: md0 stopped.
md: unbind<hde1>
md: export_rdev(hde1)
md: bind<sda1>
md: bind<sdc1>
md: bind<sdd1>
md: bind<hde1>
md: bind<sdb1>
(Continue reading)

Permalink | Reply | 3 comments |
headers
Hank Barta | 2 Oct 2005 17:13
Picon

Re: non-fresh drive?

I should have added the versions of what I'm running:
oak:~# mdadm --version
mdadm - v1.12.0 - 14 June 2005
oak:~# uname -a
Linux oak 2.6.11-1-386 #1 Mon Jun 20 20:53:17 MDT 2005 i686 GNU/Linux
oak:~#
oak:~# lvm version
  LVM version:     2.01.04 (2005-02-09)
  Library version: 1.01.04 (2005-08-02)
  Driver version:  4.4.0

--
Beautiful Sunny Winfield, Illinois
-
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |
headers
Paul Clements | 2 Oct 2005 18:02
Favicon

Re: madadm man page ambiguities: '--size' units, superblock affordance

Gordon Mohr ( <at>  Bitzi) wrote:
> My 'mdadm' (v1.6.0) man page includes:
> 
> #       -z, --size=
> #              Amount  (in  Kibibytes)  of  space  to  use  from each 
> drive in
> #              RAID1/4/5/6.  This must be a multiple of the  chunk  
> size,  and
> #              must leave about 128Kb of space at the end of the drive 
> for the
> #              RAID superblock.  If this is not specified (as it  
> normally  is
> #              not) the smallest drive (or partition) sets the size, 
> though if
> #              there is a variance among the drives  of  greater  than  
> 1%,  a
> #              warning is issued.
> 
> There are several problems when trying to interpret the phrase "This 
> must be a
> multiple of the chunk  size,  and must leave about 128Kb of space at the 
> end of
> the drive for the RAID superblock."
> 
> (1) Someone resizing an array may not know the chunk size, and it's unclear
> if assuming the default of 64 is OK, or dangerous. (My experiments show 
> that
> 'mdadm' will accept a size value that is not a multiple of 64, and will 
> update
> the array size as shown by --detail to this non-multiple size, at least for
(Continue reading)

Permalink | Reply | 1 comment |
headers
Gordon Mohr (@ Bitzi | 2 Oct 2005 22:52

Re: madadm man page ambiguities: '--size' units, superblock affordance

Thanks for the clarifications!

The precision is important in my case, because I'm trying to
shrink an existing array -- first the filesystem, then the RAID
array, then the constituent partitions. I fear if I specify
any new sizes incorrectly, the next thing on disk (superblock
or future new subsequent partition) could be overwritten and
corrupted.

There are still two areas where additional details about the
mdadm behavior would help (see below)...

Paul Clements wrote:
> Gordon Mohr ( <at>  Bitzi) wrote:
> 
>> My 'mdadm' (v1.6.0) man page includes:
>>
>> #       -z, --size=
>> #              Amount  (in  Kibibytes)  of  space  to  use  from each drive in
>> #              RAID1/4/5/6.  This must be a multiple of the  chunk  size,  and
>> #              must leave about 128Kb of space at the end of the drive  for the
>> #              RAID superblock.  If this is not specified (as it  normally  is
>> #              not) the smallest drive (or partition) sets the size, though if
>> #              there is a variance among the drives  of  greater  than  1%,  a
>> #              warning is issued.
>>
>> There are several problems when trying to interpret the phrase "This must be a
>> multiple of the chunk  size,  and must leave about 128Kb of space at the end of
>> the drive for the RAID superblock."
>>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Christopher Smith | 3 Oct 2005 05:19

Re: Best way to achieve large, expandable, cheap storage?

Tyler wrote:
> What case and power supply(s)are you using?  What raid cards are you 
> using also?

The case is a no-name job I picked up from a local PC seller:

http://www.pcicase.com.au/sub_files01.htm

It's main attraction to me was the large number of 5.25" drive bays.

The PSU is just a bog-standard 450W Antec (although since I've recently 
ugpraded the machine to dual Xeons, I should get a beefier unit).

Currently the machine has 2xPromise S150 TX4.  Previously, as the 120GB 
drives were PATA, it also had a Promise TX4000.  However, since that 
card wouldn't work with a 2.6 kernel, I used it as an excuse to get more 
drives and upgrade to a newer distro :).  The TX4s are 32 bit, 66Mhz PCI 
cards and are in 64/133Mhz PCI-X slots, so they handle four 7200rpm SATA 
drives each quite well.  I toyed with getting a single 8 port SATA card, 
but all the ones I've seen are full-blown hardware RAID, making them 
quite expensive and since I use software RAID and have 5 PCI-X slots on 
the motherboard, not worth it.  I'll run out of physical space in the 
case before I run out of PCI-X slots to drop 4-port cards into.

CS
-
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
(Continue reading)

Permalink | Reply | 0 comments |
headers
Chi McNamara | 3 Oct 2005 16:55
Picon

cials-tabs, limited supply available


Be ERECT in less than 15 mins

PRlCE: $ 2 / use

visit us: bookold.com

-
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |

Gmane