Re: recover data from linear raid
On Monday June 26, [EMAIL PROTECTED] wrote: > > This is what I get now, after creating with fdisk /dev/hdb1 and > /dev/hdc1 as linux raid autodetect partitions So I'm totally confused now. You said it was 'linear', but the boot log showed 'raid0'. The drives didn't have a partition table on them, yet it is clear from the old boot log that the did. Are you sure they are the same drives, 'cause it doesn't seem like it. You could try hunting for ext3 superblocks on the device. There might be an easier way but od -x /dev/hdb | grep '^.60 ef53 ' should find them. Once you have this information we might be able to make something work. But I feel the chances are dwindling. NeilBrown - To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: recover data from linear raid
On Monday June 26, [EMAIL PROTECTED] wrote: > > This is what I get now, after creating with fdisk /dev/hdb1 and > /dev/hdc1 as linux raid autodetect partitions So I'm totally confused now. You said it was 'linear', but the boot log showed 'raid0'. The drives didn't have a partition table on them, yet it is clear from the old boot log that the did. Are you sure they are the same drives, 'cause it doesn't seem like it. You could try hunting for ext3 superblocks on the device. There might be an easier way but od -x /dev/hdb | grep '^.60 ef53 ' should find them. Once you have this information we might be able to make something work. But I feel the chances are dwindling. NeilBrown - To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bug in 2.6.17 / mdadm 2.5.1
On Monday June 26, [EMAIL PROTECTED] wrote: > Neil Brown wrote: > > > Alternately you can apply the following patch to the kernel and > > version-1 superblocks should work better. > > -stable material? Maybe. I'm not sure it exactly qualifies, but I might try sending it to them and see what they think. NeilBrown - To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bug in 2.6.17 / mdadm 2.5.1
Neil Brown wrote: Alternately you can apply the following patch to the kernel and version-1 superblocks should work better. -stable material? - To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[-mm patch] make variables static after klibc merge
We can now make the following variables static:
- drivers/md/md.c: mdp_major
- init/main.c: envp_init[]
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
This patch was already sent on:
- 16 May 2006
drivers/md/md.c |2 +-
init/main.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
--- linux-2.6.17-rc4-mm1-full/drivers/md/md.c.old 2006-05-16
12:49:59.0 +0200
+++ linux-2.6.17-rc4-mm1-full/drivers/md/md.c 2006-05-16 12:50:17.0
+0200
@@ -2563,7 +2563,7 @@
.default_attrs = md_default_attrs,
};
-int mdp_major = 0;
+static int mdp_major = 0;
static struct kobject *md_probe(dev_t dev, int *part, void *data)
{
--- linux-2.6.17-rc4-mm1-full/init/main.c.old 2006-05-16 13:20:22.0
+0200
+++ linux-2.6.17-rc4-mm1-full/init/main.c 2006-05-16 13:20:43.0
+0200
@@ -161,7 +161,7 @@
__setup("maxcpus=", maxcpus);
static char * argv_init[MAX_INIT_ARGS+2] = { "init", NULL, };
-char * envp_init[MAX_INIT_ENVS+2] = { "HOME=/", "TERM=linux", NULL, };
+static char * envp_init[MAX_INIT_ENVS+2] = { "HOME=/", "TERM=linux", NULL, };
static const char *panic_later, *panic_param;
extern struct obs_kernel_param __setup_start[], __setup_end[];
-
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[-mm patch] drivers/md/raid5.c: remove an unused variable
This patch removes an unused variable. Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> --- linux-2.6.17-mm2-full/drivers/md/raid5.c.old2006-06-26 21:17:13.0 +0200 +++ linux-2.6.17-mm2-full/drivers/md/raid5.c2006-06-26 21:17:20.0 +0200 @@ -2827,7 +2827,6 @@ struct stripe_head *sh; int pd_idx; int raid_disks = conf->raid_disks; - int data_disks = raid_disks - conf->max_degraded; sector_t max_sector = mddev->size << 1; int sync_blocks; int still_degraded = 0; - To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: recover data from linear raid
This is what I get now, after creating with fdisk /dev/hdb1 and /dev/hdc1 as linux raid autodetect partitions mdadm -E /dev/hdb1 /dev/hdb1: Magic : a92b4efc Version : 00.90.00 UUID : a7e90d4b:f347bd0e:07ebf941:e718f695 Creation Time : Wed Mar 16 18:14:25 2005 Raid Level : raid0 Device Size : 244195904 (232.88 GiB 250.06 GB) Raid Devices : 2 Total Devices : 2 Preferred Minor : 0 Update Time : Wed Jun 21 21:57:37 2006 State : clean, no-errors Active Devices : 2 Working Devices : 2 Failed Devices : 0 Spare Devices : 0 Checksum : c8c21ed8 - correct Events : 0.82 Chunk Size : 64K Number Major Minor RaidDevice State this 0 3 650 active sync /dev/hdb1 0 0 3 650 active sync /dev/hdb1 1 1 2211 active sync /dev/hdc1 [EMAIL PROTECTED] root]# mdadm -E /dev/hdc1 /dev/hdc1: Magic : a92b4efc Version : 00.90.00 UUID : a7e90d4b:f347bd0e:07ebf941:e718f695 Creation Time : Wed Mar 16 18:14:25 2005 Raid Level : raid0 Device Size : 244195904 (232.88 GiB 250.06 GB) Raid Devices : 2 Total Devices : 2 Preferred Minor : 0 Update Time : Wed Jun 21 21:57:37 2006 State : clean, no-errors Active Devices : 2 Working Devices : 2 Failed Devices : 0 Spare Devices : 0 Checksum : c8c21ead - correct Events : 0.82 Chunk Size : 64K Number Major Minor RaidDevice State this 1 2211 active sync /dev/hdc1 0 0 3 650 active sync /dev/hdb1 1 1 2211 active sync /dev/hdc1 -- Dimitris Zilaskos Department of Physics @ Aristotle University of Thessaloniki , Greece PGP key : http://tassadar.physics.auth.gr/~dzila/pgp_public_key.asc http://egnatia.ee.auth.gr/~dzila/pgp_public_key.asc MD5sum : de2bd8f73d545f0e4caf3096894ad83f pgp_public_key.asc - To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: recover data from linear raid
I managed to get the hard disk of the retired system and this is its raid-related boot log: md: Autodetecting RAID arrays. [events: 004d] [events: 004d] md: autorun ... md: considering hdb1 ... md: adding hdb1 ... md: adding hdc1 ... md: created md0 md: bind md: bind md: running: md: hdb1's event counter: 004d md: hdc1's event counter: 004d md0: max total readahead window set to 512k md0: 2 data-disks, max readahead per data-disk: 256k raid0: looking at hdb1 raid0: comparing hdb1(244195904) with hdb1(244195904) raid0: END raid0: ==> UNIQUE raid0: 1 zones raid0: looking at hdc1 raid0: comparing hdc1(293049600) with hdb1(244195904) raid0: NOT EQUAL raid0: comparing hdc1(293049600) with hdc1(293049600) raid0: END raid0: ==> UNIQUE raid0: 2 zones raid0: FINAL 2 zones raid0: zone 0 raid0: checking hdb1 ... contained as device 0 (244195904) is smallest!. raid0: checking hdc1 ... contained as device 1 raid0: zone->nb_dev: 2, size: 488391808 raid0: current zone offset: 244195904 raid0: zone 1 raid0: checking hdb1 ... nope. raid0: checking hdc1 ... contained as device 0 (293049600) is smallest!. raid0: zone->nb_dev: 1, size: 48853696 raid0: current zone offset: 293049600 raid0: done. raid0 : md_size is 537245504 blocks. raid0 : conf->smallest->size is 48853696 blocks. raid0 : nb_zone is 11. raid0 : Allocating 88 bytes for hash. md: ... autorun DONE. As Christian said, specific error message help a lot. Assume the two devices are hdc and hde, fdisk -l /dev/hdc fdisk -l /dev/hde mdadm -E /dev/hdc mdadm -E /dev/hde and my best guess mdadm --build /dev/md0 --level linear --raid-disks 2 /dev/hdc /dev/hde fsck -n /dev/md0 (and linux-raid@vger.kernel.org might be a better mailing list for this particular sort of problem). Disk /dev/hdb: 250.0 GB, 250059350016 bytes 255 heads, 63 sectors/track, 30401 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Device BootStart EndBlocks Id System [EMAIL PROTECTED] root]# fdisk -l /dev/hdc Disk /dev/hdc: 300.0 GB, 300090728448 bytes 255 heads, 63 sectors/track, 36483 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Device BootStart EndBlocks Id System [EMAIL PROTECTED] root]# mdadm -E /dev/hdb /dev/hdb: Magic : a92b4efc Version : 00.90.00 UUID : 293be3e8:5a7ac6e7:adefc469:84f8aefb Creation Time : Fri Jun 23 15:47:10 2006 Raid Level : linear Device Size : 244198464 (232.89 GiB 250.06 GB) Raid Devices : 2 Total Devices : 2 Preferred Minor : 0 Update Time : Fri Jun 23 15:48:43 2006 State : clean, no-errors Active Devices : 2 Working Devices : 2 Failed Devices : 0 Spare Devices : 0 Checksum : f790e07f - correct Events : 0.2 Rounding : 32K Number Major Minor RaidDevice State this 0 3 640 active sync /dev/hdb 0 0 3 640 active sync /dev/hdb 1 1 2201 active sync /dev/hdc [EMAIL PROTECTED] root]# mdadm -E /dev/hdc /dev/hdc: Magic : a92b4efc Version : 00.90.00 UUID : 293be3e8:5a7ac6e7:adefc469:84f8aefb Creation Time : Fri Jun 23 15:47:10 2006 Raid Level : linear Device Size : 244198464 (232.89 GiB 250.06 GB) Raid Devices : 2 Total Devices : 2 Preferred Minor : 0 Update Time : Fri Jun 23 15:48:43 2006 State : clean, no-errors Active Devices : 2 Working Devices : 2 Failed Devices : 0 Spare Devices : 0 Checksum : f790e054 - correct Events : 0.2 Rounding : 32K Number Major Minor RaidDevice State this 1 2201 active sync /dev/hdc 0 0 3 640 active sync /dev/hdb 1 1 2201 active sync /dev/hdc [EMAIL PROTECTED] root]# mdadm --build /dev/md0 --level linear --raid-disks 2 /dev/hdb /dev/hdc mdadm: array /dev/md0 built and started. fsck -n /dev/md0 fsck 1.32 (09-Nov-2002) e2fsck 1.32 (09-Nov-2002) Couldn't find ext2 superblock, trying backup blocks... fsck.ext2: Bad magic number in super-block while trying to open /dev/md0 The superblock could not be read or does not describe a correct ext2 filesystem. If the device is valid and it really contains an ext2 filesystem (and not swap or ufs or something else), then the superblock is corrupt, and you might try running e2fsck with an alternate superblock: e2fsck -b 8193 fsck -b 8193 /dev/md0 fsck 1.32 (09-Nov-2002) e2fsck 1.32 (09-Nov-2002) fsck.ext2: Bad magic number in super-block while trying to open /dev/md0 The superblock could not be read or does not describe a correct ext2 filesystem. If the device is valid and it really contains an ext2 filesystem (and not swap or ufs or something else), then the superblock is corrupt, and you might try running e2fsck with an alternate superblock: e2fsck -b 8193 During a recovery attemp today by mistake I created a mirror a
Re: IBM xSeries stop responding during RAID1 reconstruction
Mr. James W. Laferriere wrote: Hello Gabor , On Tue, 20 Jun 2006, Gabor Gombas wrote: On Tue, Jun 20, 2006 at 03:08:59PM +0200, Niccolo Rigacci wrote: Do you know if it is possible to switch the scheduler at runtime? echo cfq > /sys/block//queue/scheduler At least one can do a ls of the /sys/block area & then do an automated echo cfq down the tree . Does anyone know of a method to set a default scheduler ? Scanning down a list or manually maintaining a list seems to be a bug in the waiting . Tia , JimL Thought I posted this... it can be set in kernel build or on the bloot parameters from grub/lilo. 2nd thought: set it to cfq by default, then at the END of rc.local, if there are no arrays rebuilding, change to something else if you like. -- bill davidsen <[EMAIL PROTECTED]> CTO TMR Associates, Inc Doing interesting things with small computers since 1979 - To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RAID5 degraded after mdadm -S, mdadm --assemble (everytime)
Ronald Lembcke wrote: Hi! I set up a RAID5 array of 4 disks. I initially created a degraded array and added the fourth disk (sda1) later. The array is "clean", but when I do mdadm -S /dev/md0 mdadm --assemble /dev/md0 /dev/sd[abcd]1 it won't start. It always says sda1 is "failed". When I remove sda1 and add it again everything seems to be fine until I stop the array. Below is the output of /proc/mdstat, mdadm -D -Q, mdadm -E and a piece of the kernel log. The output of mdadm -E looks strange for /dev/sd[bcd]1, saying "1 failed". What can I do about this? How could this happen? I mixed up the syntax when adding the fourth disk and tried these two commands (at least one didn't yield an error message): mdadm --manage -a /dev/md0 /dev/sda1 mdadm --manage -a /dev/sda1 /dev/md0 Thanks in advance ... Roni ganges:~# cat /proc/mdstat Personalities : [raid5] [raid4] md0 : active raid5 sda1[4] sdc1[0] sdb1[2] sdd1[1] 691404864 blocks super 1.0 level 5, 64k chunk, algorithm 2 [4/4] [] unused devices: I will just comment that the 0 1 2 4 numbering on the devices is unusual. When you created this did you do something which made md think there was another device, failed or missing, which was device[3]? I just looked at a bunch of my arrays and found no similar examples. -- bill davidsen <[EMAIL PROTECTED]> CTO TMR Associates, Inc Doing interesting things with small computers since 1979 - To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Large single raid and XFS or two small ones and EXT3?
Adam Talbot wrote: Not exactly sure how to tune for stripe size. What would you advise? -Adam See the -R option of mke2fs. I don't have a number for the performance impact of this, but I bet someone else on the list will. Depending on what posts you read, reports range from "measurable" to "significant," without quantifying. Note, next month I will set up either a 2x750 RAID-1 or 4x250 RAID-5 array, and if I got RAID-5 I will have the chance to run some metrics before putting the hardware into production service. I'll report on the -R option if I have any data. Bill Davidsen wrote: winspeareAdam Talbot wrote: OK, this topic I relay need to get in on. I have spent the last few week bench marking my new 1.2TB, 6 disk, RAID6 array. I wanted real numbers, not "This FS is faster because..." I have moved over 100TB of data on my new array running the bench mark testing. I have yet to have any major problems with ReiserFS, EXT2/3, JFS, or XFS. I have done extensive testing on all, including just trying to break the file system with billions of 1k files, or a 1TB file. Was able to cause some problems with EXT3 and RiserFS with the 1KB and 1TB tests, respectively. but both were fixed with a fsck. My basic test is to move all data from my old server to my new server (whitequeen2) and clock the transfer time. Whitequeen2 has very little storage. The NAS's 1.2TB of storage is attached via iSCSI and a cross over cable to the back of whitequeen2. The data is 100GB of user's files(1KB~2MB), 50GB of MP3's (1MB~5MB) and the rest is movies and system backups 600MB~2GB. Here is a copy of my current data sheet, including specs on the servers and copy times, my numbers are not perfect, but they should give you a clue about speeds... XFS wins. In many (most?) cases I'm a lot more concerned about filesystem stability than performance. That is, I want the fastest filesystem. With ext2 and ext3 I've run multiple multi-TB machines spread over four time zones, and not had a f/s problem updating ~1TB/day. Did you tune the extN filesystems to the stripe size of the raid? -- bill davidsen <[EMAIL PROTECTED]> CTO TMR Associates, Inc Doing interesting things with small computers since 1979 - To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: recover data from linear raid
As Christian said, specific error message help a lot. Assume the two devices are hdc and hde, fdisk -l /dev/hdc fdisk -l /dev/hde mdadm -E /dev/hdc mdadm -E /dev/hde and my best guess mdadm --build /dev/md0 --level linear --raid-disks 2 /dev/hdc /dev/hde fsck -n /dev/md0 (and linux-raid@vger.kernel.org might be a better mailing list for this particular sort of problem). Disk /dev/hdb: 250.0 GB, 250059350016 bytes 255 heads, 63 sectors/track, 30401 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Device BootStart EndBlocks Id System [EMAIL PROTECTED] root]# fdisk -l /dev/hdc Disk /dev/hdc: 300.0 GB, 300090728448 bytes 255 heads, 63 sectors/track, 36483 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Device BootStart EndBlocks Id System [EMAIL PROTECTED] root]# mdadm -E /dev/hdb /dev/hdb: Magic : a92b4efc Version : 00.90.00 UUID : 293be3e8:5a7ac6e7:adefc469:84f8aefb Creation Time : Fri Jun 23 15:47:10 2006 Raid Level : linear Device Size : 244198464 (232.89 GiB 250.06 GB) Raid Devices : 2 Total Devices : 2 Preferred Minor : 0 Update Time : Fri Jun 23 15:48:43 2006 State : clean, no-errors Active Devices : 2 Working Devices : 2 Failed Devices : 0 Spare Devices : 0 Checksum : f790e07f - correct Events : 0.2 Rounding : 32K Number Major Minor RaidDevice State this 0 3 640 active sync /dev/hdb 0 0 3 640 active sync /dev/hdb 1 1 2201 active sync /dev/hdc [EMAIL PROTECTED] root]# mdadm -E /dev/hdc /dev/hdc: Magic : a92b4efc Version : 00.90.00 UUID : 293be3e8:5a7ac6e7:adefc469:84f8aefb Creation Time : Fri Jun 23 15:47:10 2006 Raid Level : linear Device Size : 244198464 (232.89 GiB 250.06 GB) Raid Devices : 2 Total Devices : 2 Preferred Minor : 0 Update Time : Fri Jun 23 15:48:43 2006 State : clean, no-errors Active Devices : 2 Working Devices : 2 Failed Devices : 0 Spare Devices : 0 Checksum : f790e054 - correct Events : 0.2 Rounding : 32K Number Major Minor RaidDevice State this 1 2201 active sync /dev/hdc 0 0 3 640 active sync /dev/hdb 1 1 2201 active sync /dev/hdc [EMAIL PROTECTED] root]# mdadm --build /dev/md0 --level linear --raid-disks 2 /dev/hdb /dev/hdc mdadm: array /dev/md0 built and started. fsck -n /dev/md0 fsck 1.32 (09-Nov-2002) e2fsck 1.32 (09-Nov-2002) Couldn't find ext2 superblock, trying backup blocks... fsck.ext2: Bad magic number in super-block while trying to open /dev/md0 The superblock could not be read or does not describe a correct ext2 filesystem. If the device is valid and it really contains an ext2 filesystem (and not swap or ufs or something else), then the superblock is corrupt, and you might try running e2fsck with an alternate superblock: e2fsck -b 8193 fsck -b 8193 /dev/md0 fsck 1.32 (09-Nov-2002) e2fsck 1.32 (09-Nov-2002) fsck.ext2: Bad magic number in super-block while trying to open /dev/md0 The superblock could not be read or does not describe a correct ext2 filesystem. If the device is valid and it really contains an ext2 filesystem (and not swap or ufs or something else), then the superblock is corrupt, and you might try running e2fsck with an alternate superblock: e2fsck -b 8193 During a recovery attemp today by mistake I created a mirror array with hdb as the primary and hdc as the secondary. I interrupted the array creation almost immediately, but part of the hdc was overwritten. However the array never held more than 70 gbytes of data, so I hope everything is intact on hdb :/ Thank you all for your kind help:) -- Dimitris Zilaskos Department of Physics @ Aristotle University of Thessaloniki , Greece PGP key : http://tassadar.physics.auth.gr/~dzila/pgp_public_key.asc http://egnatia.ee.auth.gr/~dzila/pgp_public_key.asc MD5sum : de2bd8f73d545f0e4caf3096894ad83f pgp_public_key.asc - To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Is shrinking raid5 possible?
This is shrinking an array by removing drives. We were talking about shrinking an array by reducing the size of drives - a very different think. Yes I know - I just wanted to get this in as an alternative shrinking semantic. As for reducing the RAID (partition) size on the individual drives I can only see two reasons: 1) One wants to replace / add a disk but the new disk is slightly smaller than the existing ones. Actual capacity varies a lot for the same nominal capacity, especially across brands. 2) One wants to do something else with some of the space, although for a RAID5 I don't quite see the point - you'd end up with n small partitions. Shrinking a 2-way mirror or stripe this way sounds far more useful. Having RAID tightly integrated with volume management and partitions would be nice, but that's a pipe dream. (EVMS just integrates the UI somewhat, you still have to mess about with layers.) I'm not sure it is really worth the effort I'm afraid. Neither am I ... it just would have come in handy a few times, that's all. Thanks, C. - To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Multiple raids on one machine?
Gordon Henderson wrote: I use option 2 (above) all the time, and I've never noticed any performance issues. (not issues with recovery after a power failure) I'd like to think that on a modern processor the CPU can handle the parity, etc. calculations several orders of magnitude faster than the hardware can chug data to & from the drives, so all it's really adding is a tiny bit of latency... Thanks for this, and for the very informed responses from other subscribers. We have gone from 100GB of storage in May 2000 (which lasted us over a year) to 50TB today (which will last us three months), and a forecast of 200TB by this time next year! I'm learning fast :-) - To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Large single raid and XFS or two small ones and EXT3?
On Sun, 25 Jun 2006, Bill Davidsen wrote: Justin Piszcz wrote: On Sat, 24 Jun 2006, Neil Brown wrote: On Friday June 23, [EMAIL PROTECTED] wrote: The problem is that there is no cost effective backup available. One-liner questions : - How does Google make backups ? No, Google ARE the backups :-) - Aren't tapes dead yet ? LTO-3 does 300Gig, and LTO-4 is planned. They may not cope with tera-byte arrays in one hit, but they still have real value. - What about a NUMA principle applied to storage ? You mean an Hierarchical Storage Manager? Yep, they exist. I'm sure SGI, EMC and assorted other TLAs could sell you one. LTO3 is 400GB native and we've seen very good compression, so 800GB-1TB per tape. The problem is in small business use, LTO3 is costly in the 1-10TB range, and takes a lot of media changes as well. A TB of RAID-5 is ~$500, and at that small size the cost of drives and media is disproportionally high. Using more drives is cost effective, but they are not good for long term off site storage, because they're large and fragile. No obvious solutions in that price and application range that I see. -- bill davidsen <[EMAIL PROTECTED]> CTO TMR Associates, Inc Doing interesting things with small computers since 1979 In the 1-10TB range you are probably correct, as the numbers increase however, many LTO2/LTO3 drives + robotics become justifiable. - To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Multiple raids on one machine?
On Sun, 25 Jun 2006, Chris Allen wrote:
> Back to my 12 terabyte fileserver, I have decided to split the storage
> into four partitions
> each of 3TB. This way I can choose between XFS and EXT3 later on.
>
> So now, my options are between the following:
>
> 1. Single 12TB /dev/md0, partitioned into four 3TB partitions. But how do
> I do this? fdisk won't handle it. Can GNU Parted handle partitions this big?
>
> 2. Partition the raw disks into four partitions and make
> /dev/md0,md1,md2,md3.
> But am I heading for problems here? Is there going to be a big
> performance hit
> with four raid5 arrays on the same machine? Am I likely to have dataloss
> problems
> if my machine crashes?
I use option 2 (above) all the time, and I've never noticed any
performance issues. (not issues with recovery after a power failure) I'd
like to think that on a modern processor the CPU can handle the parity,
etc. calculations several orders of magnitude faster than the hardware can
chug data to & from the drives, so all it's really adding is a tiny bit of
latency...
Someone some time back on this list posted a hint that I've been using
though - you might find it handy - name the md? devices after the
partition number, if possible. So md1 would be made up from /dev/sda1,
/dev/sdb1, /dev/sdc1, etc. md2 made up from /dev/sda2, /dev/sdb2, etc. It
might just save any confusion when hot adding/removing drives, etc.
The down-side is that if you do have to remove a drive, you have to
manually 'fail' each other md device+partition for that drive, then
manually remove them before you can hot-remove the physical drive. (or
cold remove it/whatever)
So if you have /dev/md{1,2.3,4} and /dev/md3 (etc) is made from /dev/sda3,
/dev/sdb3, /dev/sdc3, and md3 (eg. /dev/sdc3) has a failure, then you need
to:
mdadm --fail /dev/md1 /dev/sdc1
mdadm --fail /dev/md2 /dev/sdc2
# mdadm --fail /dev/md3 /dev/sdc3 # already failed
mdadm --fail /dev/md4 /dev/sdc4
Then repeat, s/fail/remove/ then you can echo the right runes to
/proc/scsi/scsi and hot-remove /dev/sdc and plug a new one in.
At least, thats what I do when I've done it 'hot'. Doing it cold doesn't
really matter as the server will boot with a blank partition table in the
replaced disk and just kick it out of the array - you can then
re-partition, and mdadm --add ... the partition back into each array.
I like to keep each partition identical, if I can - heres an example:
Personalities : [raid1] [raid6]
md1 : active raid1 sdf1[5] sde1[4] sdd1[3] sdc1[2] sdb1[1] sda1[0]
248896 blocks [6/6] [UU]
md2 : active raid6 sdf2[5] sde2[4] sdd2[3] sdc2[2] sdb2[1] sda2[0]
1991680 blocks level 6, 64k chunk, algorithm 2 [6/6] [UU]
md3 : active raid6 sdf3[5] sde3[4] sdd3[3] sdc3[2] sdb3[1] sda3[0]
1991680 blocks level 6, 64k chunk, algorithm 2 [6/6] [UU]
md5 : active raid6 sdf5[5] sde5[4] sdd5[3] sdc5[2] sdb5[1] sda5[0]
3983616 blocks level 6, 64k chunk, algorithm 2 [6/6] [UU]
md6 : active raid6 sdf6[5] sde6[4] sdd6[3] sdc6[2] sdb6[1] sda6[0]
277345536 blocks level 6, 64k chunk, algorithm 2 [6/6] [UU]
md7 : active raid6 sdf7[5] sde7[4] sdd7[3] sdc7[2] sdb7[1] sda7[0]
287177472 blocks level 6, 64k chunk, algorithm 2 [6/6] [UU]
Each drive is partitioned like:
Disk /dev/sda: 255 heads, 63 sectors, 17849 cylinders
Units = cylinders of 16065 * 512 bytes
Device BootStart EndBlocks Id System
/dev/sda1 * 131248976 fd Linux raid autodetect
/dev/sda23293498015 fd Linux raid autodetect
/dev/sda394 155498015 fd Linux raid autodetect
/dev/sda4 156 17849 1421270555 Extended
/dev/sda5 156 279995998+ fd Linux raid autodetect
/dev/sda6 280 8911 69336508+ fd Linux raid autodetect
/dev/sda7 8912 17849 71794453+ fd Linux raid autodetect
(Yes, md1 is a RAID-1 striped over 6 drives! write performance might be
"sub optimal", but it's only the root partition and hardly ever written
to, and yes, swap /dev/md2 on this box is under R-6)
Gordon
-
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Is shrinking raid5 possible?
On Friday June 23, [EMAIL PROTECTED] wrote: > > Why would you ever want to reduce the size of a raid5 in this way? > > A feature that would have been useful to me a few times is the ability > to shrink an array by whole disks. > > Example: > > 8x 300 GB disks -> 2100 GB raw capacity > > shrink file system, remove 2 disks = > > 6x 300 GB disks --> 1500 GB raw capacity > This is shrinking an array by removing drives. We were talking about shrinking an array by reducing the size of drives - a very different think. Yes, it might be sometimes useful to reduce the number of drives in a raid5. This would be similar to adding a drive to a raid5 (now possible), but the data copy would have to go in a different direction, so there would need to be substantial changes to the code. I'm not sure it is really worth the effort I'm afraid, but it might get done, one day, especially if someone volunteers some code ... ;-) NeilBrown > Why? > > If you're not backed up by a company budget, moving data to an new > array (extra / larger disks) is extremely difficult. A lot of cases > will hold 8 disks but not 16, never mind the extra RAID controller. > Building another temporary server and moving the data via Gigabit is > slow and expensive as well. > > Shrinking the array step-by-step and unloading data onto a regular > filesystem on the freed disks would be a cheap (if time consuming) way > to migrate, because the data could be copied back to the new array a > disk at a time. > > Thanks, > > C. > - > To unsubscribe from this list: send the line "unsubscribe linux-raid" in > the body of a message to [EMAIL PROTECTED] > 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
