19390 root 17.49 M/s 0 B/s 0.00 % 21.36 % dd if /dev/sde bs 1M
19333 root 16.52 M/s 0 B/s 0.00 % 17.07 % dd if /dev/sdd bs 1M
19503 root 15.79 M/s 0 B/s 0.00 % 13.91 % dd if /dev/sdf bs 1M
18896 root 0 B/s 16.10 M/s 0.00 % 0.00 % ntfs-3g
/dev/sdb1 /media/ntfs3g/sdb
18909 root 0 B/s 13.49 M/s 0.00 % 0.00 % ntfs-3g
/dev/sdc1 /media/ntfs3g/sdc
18920 root 0 B/s 15.73 M/s 0.00 % 0.00 % ntfs-3g
/dev/sdn1 /media/ntfs3g/sdn
this will certainly be quicker :-)
On 17 February 2011 13:56, Simon Mcnair <simonmcnair@xxxxxxxxx> wrote:
> Phil, I think I need to connect them to the crippled machine directly,
> I was just trying to leave it alone, I know that doesn't make much
> sense but I'm more familiar with windows than Linux. The cards that I
> have are all connected at gigabit and bonded. That machine has two
> ports, so does the other. I'm running two asus p6ts (1 deluxe and 1
> se) with i7 920's
>
> I cant understand why it's so slow though I have seen some reports
> that the supermicro card is quite slow.
> Simon
> Ps thanks for the bugfixes and updates
> Simon
>
> On 17 Feb 2011, at 13:48, Phil Turmel <philip@xxxxxxxxxx> wrote:
>
>> On 02/17/2011 08:26 AM, Simon Mcnair wrote:
>>> Phil,
>>> After a couple of attempts I realised that all I needed to do was
>>> ./backup.sh sdi rather than specifying ./backup.sh /dev/sdi schoolboy
>>> error huh, rtfm.
>>>
>>> I tried modifying the code, so I could kick them all off at once, but
>>> I wanted to check that this would work from a multithreaded/sane
>>> perspective (yes I know it's a bit of IO, but iotop seems to infer I'm
>>> only getting 10M/s throughput from the disk anyway).
>>
>> That sounds suspiciously like a 100 meg ethernet bottleneck, so parallel operation won't help. If so, this'll take a very long time.
>>
>>> is this code kosha ?
>>
>> Looks pretty good. I've attached a slight update with your changes and a bugfix.
>>
>>> #! /bin/bash
>>> #
>>> function usage() {
>>> printf "Usage:\n\t%s devname\n\n" "`basename \"$0\"`"
>>> printf "'devname' must be a relative path in /dev/ to the
>>> desired block device.\n"
>>> exit 1
>>> }
>>>
>>> # Verify the supplied name is a device
>>> test -b "/dev/$1" || usage
>>>
>>> # Convert path separators and spaces into dashes
>>> outfile="`echo \"$1\" |sed -r -e 's:[ /]+:-:g'`"
>>>
>>> # Create a side-stream for computing the MD5 of the data read
>>> fifo=`mktemp -u`
>>> mkfifo $fifo || exit
>>> md5sum -b <$fifo >$2/$outfile.md5 &
>>>
>>> # Read the device and compress it
>>> dd if="/dev/$1" bs=1M | tee 2>$fifo | gzip >$2/$outfile.gz
>>>
>>> # Wait for the background task to close
>>> wait
>>>
>>> I was a little concerned as I didn't see the hdd drive LED light up
>>> for my attempt even though the file was growing nicely on my CIFS
>>> share. I'm dumping it on the 5x2TB disks (JBOD) in my windows 7 box
>>> as my Thecus is not a happy chappy and I need time to mount the DOM
>>> module in another machine to find out why.
>>
>> If you're willing to dismantle the thecus, directly connecting its drives to your crippled system will make things go much faster. You've got four empty motherboard SATA ports. You just have to watch out for the power load.
>>
>> Phil
>> <block2gz.sh>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
