Re: raid problem: after every reboot /dev/sdb1 is removed?
I had the same problem. Re-doing the partition from ext2 to linux raid fixed my problem, but I see you're already using that FS type. Maybe it was the action of re-partitioning in general that fixed my problem? You could try deleting it and re-creating that partition, syncing, and rebooting? Greg On Fri, Feb 1, 2008 at 7:52 AM, Berni [EMAIL PROTECTED] wrote: Hi! I have the following problem with my softraid (raid 1). I'm running Ubuntu 7.10 64bit with kernel 2.6.22-14-generic. After every reboot my first boot partition in md0 is not synchron. One of the disks (the sdb1) is removed. After a resynch every partition is synching. But after a reboot the state is removed. The disks are new and both seagate 250gb with exactly the same partition table. Here some config files: #cat /proc/mdstat Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10] md2 : active raid1 sda6[0] sdb6[1] 117185984 blocks [2/2] [UU] md1 : active raid1 sda5[0] sdb5[1] 1951744 blocks [2/2] [UU] md0 : active raid1 sda1[0] 19534912 blocks [2/1] [U_] this is the problem: looks like U_ after reboot unused devices: none #fdisk /dev/sda Device Boot Start End Blocks Id System /dev/sda1 1243219535008+ fd Linux raid autodetect /dev/sda22433 17264 1191380405 Extended /dev/sda3 * 17265 2045125599577+ 7 HPFS/NTFS /dev/sda4 20452 3040079915342+ 7 HPFS/NTFS /dev/sda524332675 1951866 fd Linux raid autodetect /dev/sda62676 17264 117186111 fd Linux raid autodetect #fdisk /dev/sdb Device Boot Start End Blocks Id System /dev/sdb1 1243219535008+ fd Linux raid autodetect /dev/sdb22433 17264 1191380405 Extended /dev/sdb3 17265 30400 1055149207 HPFS/NTFS /dev/sdb524332675 1951866 fd Linux raid autodetect /dev/sdb62676 17264 117186111 fd Linux raid autodetect # mount /dev/md0 on / type reiserfs (rw,notail) proc on /proc type proc (rw,noexec,nosuid,nodev) /sys on /sys type sysfs (rw,noexec,nosuid,nodev) varrun on /var/run type tmpfs (rw,noexec,nosuid,nodev,mode=0755) varlock on /var/lock type tmpfs (rw,noexec,nosuid,nodev,mode=1777) udev on /dev type tmpfs (rw,mode=0755) devshm on /dev/shm type tmpfs (rw) devpts on /dev/pts type devpts (rw,gid=5,mode=620) lrm on /lib/modules/2.6.22-14-generic/volatile type tmpfs (rw) /dev/md2 on /home type reiserfs (rw) securityfs on /sys/kernel/security type securityfs (rw) Could anyone help me to solve this problem? thanks greets Berni - 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
Re: Linux Software RAID 5 + XFS Multi-Benchmarks / 10 Raptors Again
Also, don't use ext*, XFS can be up to 2-3x faster (in many of the benchmarks). I'm going to swap file systems and give it a shot right now! :) How is stability of XFS? I heard recovery is easier with ext2/3 due to more people using it, more tools available, etc? Greg - 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: Raid over 48 disks ... for real now
I wonder how long it would take to run an fsck on one large filesystem? :) I would imagine you'd have time to order a new system, build it, and restore the backups before the fsck was done! - 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: Linux Software RAID 5 + XFS Multi-Benchmarks / 10 Raptors Again
Justin, thanks for the script. Here's my results. I ran it a few times with different tests, hence the small number of results you see here, I slowly trimmed out the obvious not-ideal sizes. System --- Athlon64 3500 2GB RAM 4x500GB WD Raid editions, raid 5. SDE is the old 4-platter version (5000YS), the others are the 3 platter version. Faster :-) /dev/sdb: Timing buffered disk reads: 240 MB in 3.00 seconds = 79.91 MB/sec /dev/sdc: Timing buffered disk reads: 248 MB in 3.01 seconds = 82.36 MB/sec /dev/sdd: Timing buffered disk reads: 248 MB in 3.02 seconds = 82.22 MB/sec /dev/sde: (older model, 4 platters instead of 3) Timing buffered disk reads: 210 MB in 3.01 seconds = 69.87 MB/sec /dev/md3: Timing buffered disk reads: 628 MB in 3.00 seconds = 209.09 MB/sec Testing --- Test was : dd if=/dev/zero of=/r1/bigfile bs=1M count=10240; sync 64-chunka.txt:2:00.63 128-chunka.txt:2:00.20 256-chunka.txt:2:01.67 512-chunka.txt:2:19.90 1024-chunka.txt:2:59.32 Test was : Unraring multipart RAR's, 1.2 gigabytes. Source and dest drive were the raid array. 64-chunkc.txt:1:04.20 128-chunkc.txt:0:49.37 256-chunkc.txt:0:48.88 512-chunkc.txt:0:41.20 1024-chunkc.txt:0:40.82 So, there's a toss up between 256 and 512. If I'm interpreting correctly here, raw throughput is better with 256, but 512 seems to work better with real-world stuff? I'll try to think up another test or two perhaps, and removing 64 as one of the possible options to save time (mke2fs takes a while on 1.5TB) Next step will be playing with read aheads and stripe cache sizes I guess! I'm open to any comments/suggestions you guys have! Greg - 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: Linux Software RAID 5 + XFS Multi-Benchmarks / 10 Raptors Again
What sort of tools are you using to get these benchmarks, and can I used them for ext3? Very interested in running this on my server. Thanks, Greg On Jan 16, 2008 11:13 AM, Justin Piszcz [EMAIL PROTECTED] wrote: For these benchmarks I timed how long it takes to extract a standard 4.4 GiB DVD: Settings: Software RAID 5 with the following settings (until I change those too): Base setup: blockdev --setra 65536 /dev/md3 echo 16384 /sys/block/md3/md/stripe_cache_size echo Disabling NCQ on all disks... for i in $DISKS do echo Disabling NCQ on $i echo 1 /sys/block/$i/device/queue_depth done p34:~# grep : *chunk* |sort -n 4-chunk.txt:0:45.31 8-chunk.txt:0:44.32 16-chunk.txt:0:41.02 32-chunk.txt:0:40.50 64-chunk.txt:0:40.88 128-chunk.txt:0:40.21 256-chunk.txt:0:40.14*** 512-chunk.txt:0:40.35 1024-chunk.txt:0:41.11 2048-chunk.txt:0:43.89 4096-chunk.txt:0:47.34 8192-chunk.txt:0:57.86 16384-chunk.txt:1:09.39 32768-chunk.txt:1:26.61 It would appear a 256 KiB chunk-size is optimal. So what about NCQ? 1=ncq_depth.txt:0:40.86*** 2=ncq_depth.txt:0:40.99 4=ncq_depth.txt:0:42.52 8=ncq_depth.txt:0:43.57 16=ncq_depth.txt:0:42.54 31=ncq_depth.txt:0:42.51 Keeping it off seems best. 1=stripe_and_read_ahead.txt:0:40.86 2=stripe_and_read_ahead.txt:0:40.99 4=stripe_and_read_ahead.txt:0:42.52 8=stripe_and_read_ahead.txt:0:43.57 16=stripe_and_read_ahead.txt:0:42.54 31=stripe_and_read_ahead.txt:0:42.51 256=stripe_and_read_ahead.txt:1:44.16 1024=stripe_and_read_ahead.txt:1:07.01 2048=stripe_and_read_ahead.txt:0:53.59 4096=stripe_and_read_ahead.txt:0:45.66 8192=stripe_and_read_ahead.txt:0:40.73 16384=stripe_and_read_ahead.txt:0:38.99** 16384=stripe_and_65536_read_ahead.txt:0:38.67 16384=stripe_and_65536_read_ahead.txt:0:38.69 (again, this is what I use from earlier benchmarks) 32768=stripe_and_read_ahead.txt:0:38.84 What about logbufs? 2=logbufs.txt:0:39.21 4=logbufs.txt:0:39.24 8=logbufs.txt:0:38.71 (again) 2=logbufs.txt:0:42.16 4=logbufs.txt:0:38.79 8=logbufs.txt:0:38.71** (yes) What about logbsize? 16k=logbsize.txt:1:09.22 32k=logbsize.txt:0:38.70 64k=logbsize.txt:0:39.04 128k=logbsize.txt:0:39.06 256k=logbsize.txt:0:38.59** (best) What about allocsize? (default=1024k) 4k=allocsize.txt:0:39.35 8k=allocsize.txt:0:38.95 16k=allocsize.txt:0:38.79 32k=allocsize.txt:0:39.71 64k=allocsize.txt:1:09.67 128k=allocsize.txt:0:39.04 256k=allocsize.txt:0:39.11 512k=allocsize.txt:0:39.01 1024k=allocsize.txt:0:38.75** (default) 2048k=allocsize.txt:0:39.07 4096k=allocsize.txt:0:39.15 8192k=allocsize.txt:0:39.40 16384k=allocsize.txt:0:39.36 What about the agcount? 2=agcount.txt:0:37.53 4=agcount.txt:0:38.56 8=agcount.txt:0:40.86 16=agcount.txt:0:39.05 32=agcount.txt:0:39.07** (default) 64=agcount.txt:0:39.29 128=agcount.txt:0:39.42 256=agcount.txt:0:38.76 512=agcount.txt:0:38.27 1024=agcount.txt:0:38.29 2048=agcount.txt:1:08.55 4096=agcount.txt:0:52.65 8192=agcount.txt:1:06.96 16384=agcount.txt:1:31.21 32768=agcount.txt:1:09.06 65536=agcount.txt:1:54.96 So far I have: p34:~# mkfs.xfs -f -l lazy-count=1,version=2,size=128m -i attr=2 /dev/md3 meta-data=/dev/md3 isize=256agcount=32, agsize=10302272 blks = sectsz=4096 attr=2 data = bsize=4096 blocks=329671296, imaxpct=25 = sunit=64 swidth=576 blks, unwritten=1 naming =version 2 bsize=4096 log =internal log bsize=4096 blocks=32768, version=2 = sectsz=4096 sunit=1 blks, lazy-count=1 realtime =none extsz=2359296 blocks=0, rtextents=0 p34:~# grep /dev/md3 /etc/fstab /dev/md3/r1 xfs noatime,nodiratime,logbufs=8,logbsize=262144 0 1 Notice how mkfs.xfs 'knows' the sunit and swidth, and it is the correct units too because it is software raid, and it pulls this information from that layer, unlike HW raid which will not have a clue of what is underneath and say sunit=0,swidth=0. However, in earlier testing I actually made them both 0 and it actually made performance better: http://home.comcast.net/~jpiszcz/sunit-swidth/results.html In any case, I am re-running bonnie++ once more with a 256 KiB chunk and will compare to those values in a bit. Justin. - 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
Change Stripe size?
So I've been slowly expanding my knowledge of mdadm/linux raid. I've got a 1 terabyte array which stores mostly large media files, and from my reading, increasing the stripe size should really help my performance Is there any way to do this to an existing array, or will I need to backup the array and re-create it with a larger stripe size? Thanks and happy new year! Greg - 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: Superblocks
Any reason 0.9 is the default? Should I be worried about using 1.0 superblocks? And can I upgrade my array from 0.9 to 1.0 superblocks? Thanks, Greg On 11/1/07, Neil Brown [EMAIL PROTECTED] wrote: On Tuesday October 30, [EMAIL PROTECTED] wrote: Which is the default type of superblock? 0.90 or 1.0? The default default is 0.90. However a local device can be set in mdadm.conf with e.g. CREATE metdata=1.0 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: Superblocks
Which is the default type of superblock? 0.90 or 1.0? On 10/30/07, Neil Brown [EMAIL PROTECTED] wrote: On Friday October 26, [EMAIL PROTECTED] wrote: Can someone help me understand superblocks and MD a little bit? I've got a raid5 array with 3 disks - sdb1, sdc1, sdd1. --examine on these 3 drives shows correct information. However, if I also examine the raw disk devices, sdb and sdd, they also appear to have superblocks with some semi valid looking information. sdc has no superblock. If a partition starts a multiple of 64K from the start of the device, and ends with about 64K of the end of the device, then a superblock on the partition will also look like a superblock on the whole device. This is one of the shortcomings of v0.90 superblocks. v1.0 doesn't have this problem. How can I clear these? If I unmount my raid, stop md0, it won't clear it. mdadm --zero-superblock device name is the best way to remove an unwanted superblock. Ofcourse in the above described case, removing the unwanted superblock will remove the wanted one aswell. [EMAIL PROTECTED] ~]# mdadm --zero-superblock /dev/hdd mdadm: Couldn't open /dev/hdd for write - not zeroing As I think someone else pointed out /dev/hdd is not /dev/sdd. 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
Superblocks
Can someone help me understand superblocks and MD a little bit? I've got a raid5 array with 3 disks - sdb1, sdc1, sdd1. --examine on these 3 drives shows correct information. However, if I also examine the raw disk devices, sdb and sdd, they also appear to have superblocks with some semi valid looking information. sdc has no superblock. How can I clear these? If I unmount my raid, stop md0, it won't clear it. [EMAIL PROTECTED] ~]# mdadm --zero-superblock /dev/hdd mdadm: Couldn't open /dev/hdd for write - not zeroing I'd like to rule out these oddities before I start on my next troubleshooting of why my array rebuilds every time I reboot :) Thanks, Greg - 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
