Sil680 Not Recognized by Fedora
OK. I'm tired. Going to make this quick. Sil680 ATA RAID0 stripe set not recognized automatically by Fedora. Tried reinstall of Fedora. Does not recognize the RAID0 set I created. ARGH.
Saved by MDADM
I had to dust off my very, very rusty Linux RAID creation skills and manually create a software RAID set. In short:
- fdisk to mark the drives as part of a raid set
- use mdadm to make the raid set active
- create a mdadm.conf for the array
- put it in /etc/fstab
- format the stripe set
Here is the most important snip of what I did:
[root@computer /]# mdadm --create /dev/md0 --level=0 --raid-devices=2 /dev/hdg1 /dev/hdh1
mdadm: array /dev/md0 started.
[root@computer /]# mdadm --detail --scan >> /etc/mdadm.conf
[root@computer /]# cat /etc/mdadm.conf
DEVICE /dev/hdg* /dev/hdh*
ARRAY /dev/md0 level=raid0 num-devices=2 UUID=9c4c078f:8935e3e4:bfface8f:6a3c2c18
devices=/dev/hdg1,/dev/hdh1
[root@computer RPMS]# cat /etc/fstab
# This file is edited by fstab-sync - see 'man fstab-sync' for details
LABEL=/ / ext3 defaults 1 1
LABEL=/boot /boot ext3 defaults 1 2
/dev/devpts /dev/pts devpts gid=5,mode=620 0 0
/dev/shm /dev/shm tmpfs defaults 0 0
/dev/proc /proc proc defaults 0 0
/dev/sys /sys sysfs defaults 0 0
/dev/hda5 swap swap defaults 0 0
/dev/fd0 /media/floppy auto pamconsole,exec,noauto,managed 0 0
/dev/hdc /media/cdrecorder auto pamconsole,exec,noauto,managed 0 0
/dev/md0 /mnt/videos ext2 defaults 1 1
[root@computer /]# mkfs.ext2 /dev/md0
mke2fs 1.37 (21-Mar-2005)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
29310976 inodes, 58609088 blocks
2930454 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=58720256
1789 block groups
32768 blocks per group, 32768 fragments per group
16384 inodes per group
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
4096000, 7962624, 11239424, 20480000, 23887872
Writing inode tables: done
Writing superblocks and filesystem accounting information: done
This filesystem will be automatically checked every 32 mounts or
180 days, whichever comes first. Use tune2fs -c or -i to override.
Congrats to me/Girlfriend Doesn't Care
Pretty good for a guy who didn't know mdadm before tonight. So yeah! RAID0 set works! Hoohah! Copied a movie to it and then tested it in Cinelerra. HOLY SMOKES! Getting 50fps on a 1280x720 HDV movie! Damn that's fast! I can't understand why my girlfriend doesn't care about this at 1am??!
Gotta crash. I think my work is done here.
Update, 9/11/07:
Here is a very nicely organized article on adding new hard drives to Fedora:
http://fedoranews.org/tchung/storage/
Showing posts with label configuration. Show all posts
Showing posts with label configuration. Show all posts
Sunday, August 20, 2006
system reconfig, final entry
If this post was useful to you..consider buying me a beer via PayPal!
Even a $1 Draft will keep the Mule happily working..and help pay for equipment upgrades!
Friday, March 10, 2006
optimal drive/partition setup for Cinelerra
To keep it simple, I would use five drives and do four logical partitions. This would allow for all filesystems to be on separate drive spindles:
- one system drive for /root, /usr, etc - ext3
- one storage drive for source files - ext3
- one working drive for index files in .bcast - ext2
- two working drives in RAID0 (stripe set) for destination render - ext2
If you only have four drives, just keep the source files on the system drive. I would think the index files would be the most used/most reads. I have to test this use "iostat -x" to monitor read/write stats of each physical device. I assume the render partition would be the heaviest hit, so make that your RAID stripe. You can do software RAID, but as a person who runs a decent sized HP web server farm, we've always depended on hardware RAID because CPU cycles are offloaded to the RAID card itself, rather than the operating system using CPU cycles for software RAID. Since rendering is pretty much all CPU, except for the input/index file reads and the destination render file writes, it makes sense that software RAID would tend to slow your rendering down.
Finally, ext2 is very important..no journaling necessary for the working drives..just storage.
When I used Adobe Premiere, I noticed that my ATI All In Wonder actually sped up the MPEG2 render times by 50%. However, I haven't been able to get the fglrx driver to work w/my dual monitor setup on FC4. Fglrx works with one monitor, but dammit, there's no way I'm going back to just one monitor! But I will need to test out whether or not the fglrx driver speeds rendering for Cinelerra as it does Premiere.
- one system drive for /root, /usr, etc - ext3
- one storage drive for source files - ext3
- one working drive for index files in .bcast - ext2
- two working drives in RAID0 (stripe set) for destination render - ext2
If you only have four drives, just keep the source files on the system drive. I would think the index files would be the most used/most reads. I have to test this use "iostat -x
Finally, ext2 is very important..no journaling necessary for the working drives..just storage.
When I used Adobe Premiere, I noticed that my ATI All In Wonder actually sped up the MPEG2 render times by 50%. However, I haven't been able to get the fglrx driver to work w/my dual monitor setup on FC4. Fglrx works with one monitor, but dammit, there's no way I'm going back to just one monitor! But I will need to test out whether or not the fglrx driver speeds rendering for Cinelerra as it does Premiere.
Labels:
ati,
configuration,
fglrx,
hardware,
performance,
premiere,
raid
If this post was useful to you..consider buying me a beer via PayPal!
Even a $1 Draft will keep the Mule happily working..and help pay for equipment upgrades!
Subscribe to:
Posts (Atom)
