All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nagy Zoltan <kirk@bteam.hu>
To: linux-raid@vger.kernel.org
Subject: component growing in raid5
Date: Sun, 23 Mar 2008 07:59:04 +0100	[thread overview]
Message-ID: <47E5FFB8.5030903@bteam.hu> (raw)

[-- Attachment #1: Type: text/plain, Size: 1236 bytes --]

hi all,

i've set up a two dimensional array:
    * leaf nodes composes raid5 arrays from their disks, and export it 
as a iSCSI target
    * the root node creates a raid5 on top of the exported targets

in this setup i will have to face that an array component can(and would) 
grow, so i
created a test case for this to see what comes out ;)
    * after growing the components mdadm won't recognized them anymore 
as an array member
        (because there are no superblock at the end of the device - last 
64k?)
       i've tried to inform mdadm about the size of the components, but 
it sad no ;)
    * i've added an arbitary superblock copy operation after the 
expansion, to make possible for
   mdadm to recognize and assemble the array - it's working, and passes 
my test.

is there a less 'funky' solution for this ;)
can i run into any trouble when doing this on the real system?

one more thing: when i first assembled the array with 4096KB chunks, 
i've run into the
'2.6.24-rc6 reproducible raid5 hang' bug, but it won't resume after 
changing
'stripe_cache_size' even after i applied the patch manually to (2.6.24.2)
i've upgraded to 2.6.25-rc6 since then it runs smootly.
- thank you all for hunting that bug down.

kirk


[-- Attachment #2: raid-test.bash --]
[-- Type: text/plain, Size: 2334 bytes --]

#!/bin/bash

t=32768	# size in blocks

xall()
{
	for i in `seq 0 7`;do
		$*
	done
}

mkdir -p part data orig

echo "*** $1"
case "$1" in
	test)
			export		FS_DEV=/dev/md0
			$0 create					&&
			$0 createfs				&&
			$0 stop					&&
			$0 expand					&&
			$0 copy-sb				&&
			$0 lo_up					&&
			$0 assemble				&&
			$0 raid-expand				&&
			$0 fs-expand				&&
			$0 fs-check
			echo "---closing---"
			$0 stop
		;;
	test2)
			export		FS_DEV=/dev/mapper/rt
			$0 create					&&
			$0 crypt /dev/md0			&&
			$0 crypt-open				&&
			$0 createfs				&&
			$0 crypt-close				&&
			$0 stop					&&
			$0 expand					&&
			$0 copy-sb				&&
			$0 lo_up					&&
			$0 assemble				&&
			$0 raid-expand				&&
			$0 crypt-open				&&
			$0 fs-expand				&&
			$0 fs-check
			echo "---closing---"
			$0 stop
		;;
	zero)
			q(){	
				rm -f part/$i;	touch part/$i;	}
			xall q
		;;
	expand)
			cp part/{0..7} orig/
			q(){	
				dd if=/dev/zero count=$t >> part/$i;		}
			xall q
		;;
	raid-expand)
			i=0
			s=`stat --printf '%s' part/$i`;
			x=$[ ($s / 1024)-64 ]
			mdadm --grow -z $x /dev/md0
			
		;;
	create)
			$0 zero
			$0 expand
			$0 lo_up
			mdadm -Cv -n8 -l5 /dev/md0 /dev/loop{0..7}
		;;
	crypt)
			dd if=/dev/urandom count=1 of=key
			cryptsetup luksFormat /dev/md0 key				||	exit 1
		;;
	crypt-open)
			cryptsetup luksOpen /dev/md0 rt --key-file key	||	exit1
		;;
	crypt-close)
			cryptsetup luksClose rt						||	exit 1
		;;
	fs-expand)
			[ "$FS_DEV" == "" ] && echo "!!! FS_DEV not set" && exit 1
			mount $FS_DEV data
			xfs_growfs data
			umount data
		;;
	fs-check)
			[ "$FS_DEV" == "" ] && echo "!!! FS_DEV not set" && exit 1
			mount $FS_DEV data
			md5sum -c hash && echo ok || echo error
			umount data
		;;
	createfs)
			[ "$FS_DEV" == "" ] && echo "!!! FS_DEV not set" && exit 1
			mkfs.xfs $FS_DEV
			mount $FS_DEV data
			dd if=/dev/urandom of=data/junk
			md5sum data/junk | tee hash
			umount data
		;;
	lo_up)
			q(){
				losetup /dev/loop$i part/$i;	}
			xall q
		;;
	lo_down)
			q(){
				losetup -d /dev/loop$i;	}
			xall q
		;;
	assemble)
			mdadm -Av /dev/md0 /dev/loop{0..7}
		;;
	stop)
			umount data
			$0 crypt-close
			mdadm -S /dev/md0
			$0 lo_down
		;;
	copy-sb)
			q(){
				s=`stat --printf '%s' part/$i`;
				tail -c 65536 orig/$i | dd bs=1 seek=$[ $s - 65536 ] of=part/$i;	}
			xall q
		;;
	*)	echo "asd"
		;;
esac

             reply	other threads:[~2008-03-23  6:59 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-03-23  6:59 Nagy Zoltan [this message]
2008-03-23 11:24 ` component growing in raid5 Peter Grandi
2008-03-24  7:09 ` Peter Rabbitson
2008-03-24  7:09 ` Peter Rabbitson
2008-03-24 15:17   ` Nagy Zoltan
2008-03-24 15:42     ` Peter Rabbitson
2008-03-24 16:52       ` Nagy Zoltan
2008-03-25 13:06     ` Peter Grandi
2008-03-25 13:38       ` Mattias Wadenstein
2008-03-25 20:02         ` Peter Grandi
2008-03-27 20:44           ` Mattias Wadenstein
2008-03-27 22:09             ` Richard Scobie
2008-03-28  8:07               ` Mattias Wadenstein

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=47E5FFB8.5030903@bteam.hu \
    --to=kirk@bteam.hu \
    --cc=linux-raid@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.