You are not logged in.
Perhaps transferring the subject raid is possible with dd command although the arrangement seems too far out.
The data is on separate devices altho the uuid is identical for the /dev/md0 partitions. However, the boot and swap are on partitions separate from /dev/md0 which is the root partition.
If I should attempt to run ...dd if=/dev/md0 of=/dev/md1...... after setting up /dev/md1 in a compatible format, what is likely to occur?
I haven't heard of any activity of this nature and am curious as to the outcome. I am assuming that dd has no regard for partitions and will transfer whatever appears on the device although striping may negate the process.
If dd is not appropo, is there another way to do the transfer?
EDIT: Perhaps dd the two drives separately and mdadm --assemble the md1 array afterwards?
Last edited by lilsirecho (2011-10-26 17:55:43)
Prediction...This year will be a very odd year!
Hard work does not kill people but why risk it: Charlie Mccarthy
A man is not complete until he is married..then..he is finished.
When ALL is lost, what can be found? Even bytes get lonely for a little bit! X-ray confirms Iam spineless!
Offline
Performed a dd for each of two devices and ran ...mdadm --assemble --scan.. when completed and devices installed into ports.
The raid0 devices are now installed in 16GB CF devices versus the original 8GB devices and has successfully booted into ArchLinux and is supporting this post.
Thus, it is possible to boot from raid0, dd the raid to larger devices and maintain high boot -up speed without losing performance in running the system. Jumanji provides instantaneous browsing for selected url's.
I have learned not to update to Linux3.0 since it does not respond to mdadm nor to partition boot AFAICT.
DD is often called the data destructor but in my case its doubly delicious!!!
Hope this encourages other users...................
Prediction...This year will be a very odd year!
Hard work does not kill people but why risk it: Charlie Mccarthy
A man is not complete until he is married..then..he is finished.
When ALL is lost, what can be found? Even bytes get lonely for a little bit! X-ray confirms Iam spineless!
Offline
The results of hdparm on the raid0 in use:
sh-4.2# hdparm -t /dev/md0 /dev/sda /dev/sdb /dev/sdc
/dev/md0:
Timing buffered disk reads: 524 MB in 3.00 seconds = 174.61 MB/sec
/dev/sda:
Timing buffered disk reads: 226 MB in 3.00 seconds = 75.25 MB/sec
/dev/sdb:
Timing buffered disk reads: 224 MB in 3.01 seconds = 74.40 MB/sec
/dev/sdc:
Timing buffered disk reads: 90 MB in 3.01 seconds = 29.90 MB/sec
sh-4.2# It certainly shows in performance of all the installed packages....
Prediction...This year will be a very odd year!
Hard work does not kill people but why risk it: Charlie Mccarthy
A man is not complete until he is married..then..he is finished.
When ALL is lost, what can be found? Even bytes get lonely for a little bit! X-ray confirms Iam spineless!
Offline
Raid0 is made up of two 16GB 400x CF flash cards connected with adapters to sataII ports.
Prediction...This year will be a very odd year!
Hard work does not kill people but why risk it: Charlie Mccarthy
A man is not complete until he is married..then..he is finished.
When ALL is lost, what can be found? Even bytes get lonely for a little bit! X-ray confirms Iam spineless!
Offline
Interested in the /dev/md0 results so repeated the hdparm several times....
sh-4.2# hdparm -t /dev/md0
/dev/md0:
Timing buffered disk reads: 536 MB in 3.01 seconds = 178.33 MB/sec
sh-4.2# hdparm -t /dev/md0
/dev/md0:
Timing buffered disk reads: 536 MB in 3.00 seconds = 178.48 MB/sec
sh-4.2#
sh-4.2# hdparm -t /dev/md0
/dev/md0:
Timing buffered disk reads: 536 MB in 3.00 seconds = 178.42 MB/sec
sh-4.2# hdparm -t /dev/md0
/dev/md0:
Timing buffered disk reads: 536 MB in 3.00 seconds = 178.61 MB/sec
sh-4.2# cat /proc/mdstat
Personalities : [raid0]
md0 : active raid0 sda2[0] sdb2[1]
15588864 blocks super 1.2 512k chunks
unused devices: <none>
sh-4.2# It seems repeatable and still much faster than the sum of the two CF card readings taken earlier.
Probably isn't correct?
Prediction...This year will be a very odd year!
Hard work does not kill people but why risk it: Charlie Mccarthy
A man is not complete until he is married..then..he is finished.
When ALL is lost, what can be found? Even bytes get lonely for a little bit! X-ray confirms Iam spineless!
Offline
The mystery is solved. The component devices have better speeds displayed after running hdparm more than once only.
sh-4.2# hdparm -t /dev/sdb
/dev/sdb:
Timing buffered disk reads: 230 MB in 3.01 seconds = 76.37 MB/sec
sh-4.2# hdparm -t /dev/sdb
/dev/sdb:
Timing buffered disk reads: 258 MB in 3.02 seconds = 85.53 MB/sec
sh-4.2# hdparm -t /dev/sdb
/dev/sdb:
Timing buffered disk reads: 258 MB in 3.01 seconds = 85.60 MB/sec
sh-4.2# hdparm -t /dev/sdb
/dev/sdb:
Timing buffered disk reads: 258 MB in 3.02 seconds = 85.52 MB/sec
sh-4.2# hdparm -t /dev/sda
/dev/sda:
Timing buffered disk reads: 226 MB in 3.01 seconds = 74.97 MB/sec
sh-4.2# hdparm -t /dev/sda
/dev/sda:
Timing buffered disk reads: 250 MB in 3.01 seconds = 82.94 MB/sec
sh-4.2# hdparm -t /dev/sda
/dev/sda:
Timing buffered disk reads: 258 MB in 3.03 seconds = 85.28 MB/sec
sh-4.2# hdparm -t /dev/sda
/dev/sda:
Timing buffered disk reads: 256 MB in 3.00 seconds = 85.21 MB/sec
sh-4.2# So there! Twice 85 puts it in line with /dev/md0......
Prediction...This year will be a very odd year!
Hard work does not kill people but why risk it: Charlie Mccarthy
A man is not complete until he is married..then..he is finished.
When ALL is lost, what can be found? Even bytes get lonely for a little bit! X-ray confirms Iam spineless!
Offline
Only one more thing to solve and I am through.
The dd of the previous raid0 devices produced a viable raid0 bootable pair of 16GB devices(verusu8GB originally). However, the size constraints of the 8GB devices was transferred to the 16GB devices so they are not utilizing the full 16GB of the devices.
mdadm has a "grow" technique for increasing the size of raid elements but it isn't provided with examples to define how it is applied.
Perhaps some expert can advise as to the procedure to allow the remaining device size to be included. Perhaps it has to be established during the dd operation?
Prediction...This year will be a very odd year!
Hard work does not kill people but why risk it: Charlie Mccarthy
A man is not complete until he is married..then..he is finished.
When ALL is lost, what can be found? Even bytes get lonely for a little bit! X-ray confirms Iam spineless!
Offline
Performed the reinstall of the raid0 to a newly formatted pair of 16GB CF cards to insure they have full-sized capacity.
Now when I dd the raid0 devices into the newly formatted 16GB CF cards I have 29.6GB of /dev/md0 available.
So the difficulty has been resolved by first formatting to establish the size of the partitions in the new devices.
I originally did not do the formatting, leaving that up to the raid0 devices in dd. My oops!!!!
The basic problem remains, however, in the upgrade to linux, mdadm does not perform as before.
Perhaps in the coming couple of years that might get changed?
Thus, my raid0 is kernel26 version 39 bootable, (ten seconds to xfce4).
As to the --grow of raid0 to increase the md0 size...it does not work for raid0. However, to --grow a raid0 array, --grow can be utilized as I have demonstrated in creating a 5 device raid0 array on another post, building it one device at a time from an initial raid0 using the --grow option.
Prediction...This year will be a very odd year!
Hard work does not kill people but why risk it: Charlie Mccarthy
A man is not complete until he is married..then..he is finished.
When ALL is lost, what can be found? Even bytes get lonely for a little bit! X-ray confirms Iam spineless!
Offline
As of this posting, I have successfully installed raid0 bootable kernel26 on two 8GB CF devices , dd'ed that raid0 array to GROW to a pair of 16GB CF cards pre-formatted to accept the raid params.
Thus it is possible not only to GROW the nember of devices but also the size of the resulting array(requiring new devices to do it).
A new definition for GROW in mdadm!!!!!
In addition, as reported on another post, I was able to upgrade the raid0 array to the latest linux3.0.7-1 with pacman -Syu(317 packages)!!! These were required to upgrade from kernel26 to the new kernel.
Attempts to do this raid0 activity from archlinux.iso's was unsuccessful . The original raid0 was generated from the older 2010-05 some time back and it doesn't respond the same today.
The boot time is 9 seconds with this new kernel to xfce4 Desktop. Jumanji is terrific for browser!!!
Happy camper!!!!
X86_64
Last edited by lilsirecho (2011-10-29 04:29:50)
Prediction...This year will be a very odd year!
Hard work does not kill people but why risk it: Charlie Mccarthy
A man is not complete until he is married..then..he is finished.
When ALL is lost, what can be found? Even bytes get lonely for a little bit! X-ray confirms Iam spineless!
Offline