I got a WD 1TB My Book with eSATA/USB/Firewire400 connectivity to backup data on a client Centos 5.1 machine.
USB 2.0 works fine out of the box but is rather slow, Nautilus predicts about 1+ hour to fully backup just one day's worth of data or about 100GB.
So I was hoping Firewire would be faster, which is why we got the version with all 3 interfaces to experiment with first.
Following the suggestions given to another user here http://www.centos.org/modules/newbb/viewtopic.php?topic_id=15767&forum=3...
I updated the system's kernel to the CentoPlus [noob@localhost ~]$ uname -s -r Linux 2.6.18-92.1.10.el5
After a reboot, everything appears to work as expected, with the motherboard's TI Firewire controller detected [root@localhost ~]# lspci | grep 1394 04:07.0 FireWire (IEEE 1394): Texas Instruments TSB43AB23 IEEE-1394a-2000 Controller (PHY/Link)
However, now I'm stuck as the system does not appear to detect the drive when I connect the firewire cable and turn it on. I've followed some of the suggestions to check the drive status like "fdisk -l" but this only shows the drives already installed in the system "tail -f /var/log/dmesg" shows no new messages when the drive is connected/powered on
So I'm at a loss as to what else I should be doing to get Firewire to work and will appreciate any help on this.
Thanks!
On Wed, Aug 13, 2008 at 12:59 AM, Noob Centos Admin centos.admin@gmail.com wrote:
I got a WD 1TB My Book with eSATA/USB/Firewire400 connectivity to backup data on a client Centos 5.1 machine.
USB 2.0 works fine out of the box but is rather slow, Nautilus predicts about 1+ hour to fully backup just one day's worth of data or about 100GB.
So I was hoping Firewire would be faster, which is why we got the version with all 3 interfaces to experiment with first.
Following the suggestions given to another user here http://www.centos.org/modules/newbb/viewtopic.php?topic_id=15767&forum=3...
I updated the system's kernel to the CentoPlus [noob@localhost ~]$ uname -s -r Linux 2.6.18-92.1.10.el5
If that is the output, you are not running the centosplus kernel. It is supposed to be:
Linux 2.6.18-92.1.10.el5.centos.plus
(See http://www.centos.org/modules/newbb/viewtopic.php?topic_id=15788&forum=3... )
Akemi (nick toracat)
Noob Centos Admin wrote:
I got a WD 1TB My Book with eSATA/USB/Firewire400 connectivity to backup data on a client Centos 5.1 machine.
USB 2.0 works fine out of the box but is rather slow, Nautilus predicts about 1+ hour to fully backup just one day's worth of data or about 100GB.
So I was hoping Firewire would be faster, which is why we got the version with all 3 interfaces to experiment with first.
Following the suggestions given to another user here http://www.centos.org/modules/newbb/viewtopic.php?topic_id=15767&forum=3... http://www.centos.org/modules/newbb/viewtopic.php?topic_id=15767&forum=37
I updated the system's kernel to the CentoPlus [noob@localhost ~]$ uname -s -r Linux 2.6.18-92.1.10.el5
After a reboot, everything appears to work as expected, with the motherboard's TI Firewire controller detected [root@localhost ~]# lspci | grep 1394 04:07.0 FireWire (IEEE 1394): Texas Instruments TSB43AB23 IEEE-1394a-2000 Controller (PHY/Link)
However, now I'm stuck as the system does not appear to detect the drive when I connect the firewire cable and turn it on. I've followed some of the suggestions to check the drive status like "fdisk -l" but this only shows the drives already installed in the system "tail -f /var/log/dmesg" shows no new messages when the drive is connected/powered on
So I'm at a loss as to what else I should be doing to get Firewire to work and will appreciate any help on this.
Thanks!
2 things jump out: 1. As has already been pointed out that is not a Centos Plus kernel. Did you reboot after installing the new kernel? (You have to reboot for a kernel update in order to be running the new kernel). 2. 1 hour to copy 100GB sounds like a very good speed. Obviously the eSATA interface will be the fastest as it will the the same as having it plugged directly into the SATA controller. For reference I recently copied 73GB from an internal SATA drive to an internal (software) raid0 array (made up of 2 SATA disks), and that took 1.5hours. Regards Laurence
On Wed, Aug 13, 2008 at 4:50 PM, Laurence Alexander Hurst < L.A.Hurst@lboro.ac.uk> wrote:
2 things jump out: 1. As has already been pointed out that is not a Centos Plus kernel. Did you reboot after installing the new kernel? (You have to reboot for a kernel update in order to be running the new kernel).
Thanks Akemi & Lawrence for pointing out the obvious that I was blind to! :D I overlooked the exclude line for the Centos Update repo so yum took the wrong kernel update instead. Now downloading 2.6.18-92.1.10.el5.centos.plus and hopes everything will work after this.
2. 1 hour to copy 100GB sounds like a very good speed. Obviously the
eSATA interface will be the fastest as it will the the same as having it plugged directly into the SATA controller. For reference I recently copied 73GB from an internal SATA drive to an internal (software) raid0 array (made up of 2 SATA disks), and that took 1.5hours.
The first day's transfer just completed and it took about 1hr 10 minutes for 101GB, from du -h, which I think is in terms of 1024. So that's like 24.6MB/s which admittedly appears to be around the maximum real world data transfer rate for USB 2.0. According to some reviews of this WD model, the Firewire was supposedly up to 1/3 faster (they had figures of 35MBps vs 44Mbps).
So I am hoping to see a similar speed from the Firewire here to save some 20 minutes of waiting time, a whole week's backup would be almost 2.5 hours of savings!
Going to reboot the system now with the new kernel and hopes I don't lose the NIC or something :D
Noob Centos Admin schrieb:
The first day's transfer just completed and it took about 1hr 10 minutes for 101GB, from du -h, which I think is in terms of 1024. So that's like 24.6MB/s which admittedly appears to be around the maximum real world data transfer rate for USB 2.0. According to some reviews of this WD model, the Firewire was supposedly up to 1/3 faster (they had figures of 35MBps vs 44Mbps).
So I am hoping to see a similar speed from the Firewire here to save some 20 minutes of waiting time, a whole week's backup would be almost 2.5 hours of savings!
Going to reboot the system now with the new kernel and hopes I don't lose the NIC or something :D
The problem with Firewire is that you need a) a "good" chip in the controller b) a "good" chip in the Firewire-to-SATA controller in the external unit (there are no native firewire disks...)
That's what makes IEEE1394 always a bit of a gamble.
There's a reason someone came up with this eSATA stuff...
Rainer
On Wed, Aug 13, 2008 at 5:16 PM, Rainer Duffner rainer@ultra-secure.dewrote:
There's a reason someone came up with this eSATA stuff...
Unfortunately the machine has no more spare SATA connectors. Installing an eSATA card and such, would probably be yet another learning experience on a machine the client is not particularly keen on seening downtime as it's collecting data 24/7 :(
The kernel update was successful and dmesg returns the following ieee1394: The root node is not cycle master capable; selecting a new root node and resetting... ieee1394: Error parsing configrom for node 0-00:1023 ieee1394: Node changed: 0-00:1023 -> 0-01:1023 ieee1394: Node added: ID:BUS[0-00:1023] GUID[0090a9f6717e5649] ieee1394: sbp2: Driver forced to serialize I/O (serialize_io=1) ieee1394: sbp2: Try serialize_io=0 for better performance scsi6 : SBP-2 IEEE-1394 ieee1394: sbp2: Logged into SBP-2 device ieee1394: Node 0-00:1023: Max speed [S400] - Max payload [2048] Vendor: WD Model: My Book Rev: 1028 Type: Direct-Access ANSI SCSI revision: 04 SCSI device sde: 1953525168 512-byte hdwr sectors (1000205 MB) sde: Write Protect is off sde: Mode Sense: 10 00 00 00 sde: cache data unavailable sde: assuming drive cache: write through SCSI device sde: 1953525168 512-byte hdwr sectors (1000205 MB) sde: Write Protect is off sde: Mode Sense: 10 00 00 00 sde: cache data unavailable sde: assuming drive cache: write through sde:<6>sd 6:0:0:0: Device not ready: <6>: Current: sense key: Not Ready Add. Sense: Logical unit not ready, initializing command required
end_request: I/O error, dev sde, sector 0 Buffer I/O error on device sde, logical block 0 sd 6:0:0:0: Device not ready: <6>: Current: sense key: Not Ready Add. Sense: Logical unit not ready, initializing command required
end_request: I/O error, dev sde, sector 0 Buffer I/O error on device sde, logical block 0 sd 6:0:0:0: Device not ready: <6>: Current: sense key: Not Ready Add. Sense: Logical unit not ready, initializing command required
end_request: I/O error, dev sde, sector 0 Buffer I/O error on device sde, logical block 0 sd 6:0:0:0: Device not ready: <6>: Current: sense key: Not Ready Add. Sense: Logical unit not ready, initializing command required
end_request: I/O error, dev sde, sector 0 Buffer I/O error on device sde, logical block 0 ldm_validate_partition_table(): Disk read failed. Dev sde: unable to read RDB block 0 unable to read partition table sd 6:0:0:0: Attached scsi disk sde sd 6:0:0:0: Attached scsi generic sg4 type 0 scsi7 : SBP-2 IEEE-1394 ieee1394: sbp2: Logged into SBP-2 device ieee1394: Node 0-00:1023: Max speed [S400] - Max payload [2048] Vendor: WD Model: My Book Device Rev: Type: Enclosure ANSI SCSI revision: 04 scsi 7:0:1:0: Attached scsi generic sg5 type 13
fdisk -l Disk /dev/sde: 1000.2 GB, 1000204886016 bytes 255 heads, 63 sectors/track, 121601 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System /dev/sde1 * 1 121601 976760001 c W95 FAT32 (LBA)
The problem now is when I try to mount /dev/sde1, mount tells me that special device /dev/sde1 does not exist.
Neither does trying to mount /dev/sg4 or /dev/sg5 works, mount says they are "not a block device".
What should I be trying next? Thanks!
Noob Centos Admin schrieb:
fdisk -l Disk /dev/sde: 1000.2 GB, 1000204886016 bytes 255 heads, 63 sectors/track, 121601 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System /dev/sde1 * 1 121601 976760001 c W95 FAT32 (LBA)
The problem now is when I try to mount /dev/sde1, mount tells me that special device /dev/sde1 does not exist.
Neither does trying to mount /dev/sg4 or /dev/sg5 works, mount says they are "not a block device".
What should I be trying next? Thanks!
Maybe format it with ext3? ;-)
Rainer
On Wednesday, August 13, 2008 11:47 AM +0200 Rainer Duffner rainer@ultra-secure.de wrote:
Maybe format it with ext3? ;-)
The biggest problem with FAT32 is that it's limited to 2 GB files. My full dump is 200 GB, and I've found the "one file" dump more reliable and efficient than the multi-file feature, which breaks the dump into lots of little 1 GB files.
I format mine with NTFS for OS interoperability and mount using the ntfs-3g FUSE filesystem.
Say the partition is labeled "Backup1". Then I can mount it with:
mount /mnt/Backup /dev/disk/by-label/Backup1 -t ntfs-3g
Scratch that last message. I removed the drive to verify the copied content on another machine and realized I forgot to copy one folder. Plugged it back, with the wrong connector, using the Firewire instead of USB, probably because my mind was still on the Firewire issue.
This time round, gnome desktop automounted the drive and there it was on my desktop to my surprise.
Checking with mount /dev/sde1 on /media/My Book type vfat (rw,noexec,nosuid,nodev,shortname=winnt,uid=502)
I've no idea why or what happened, just glad it works! :D
Now testing it out with another day's data about 112G worth and Nautilus is estimating about 60 minutes, so that's about 31.8MB/s or 29% faster. Although Nautilus was a bit optimistic with the previous transfer so the Firewire still likely a good 20% to 25% faster.
On Wednesday, August 13, 2008 5:28 PM +0800 Noob Centos Admin centos.admin@gmail.com wrote:
ieee1394: Node 0-00:1023: Max speed [S400] - Max payload [2048]
S400 is 400 megabits, while USB 2 is 480 megabits. Firewire has less packet overhead, which might explain WD's claim that the FireWire interface is a little faster.
On Wed, Aug 13, 2008, Kenneth Porter wrote:
On Wednesday, August 13, 2008 5:28 PM +0800 Noob Centos Admin centos.admin@gmail.com wrote:
ieee1394: Node 0-00:1023: Max speed [S400] - Max payload [2048]
S400 is 400 megabits, while USB 2 is 480 megabits. Firewire has less packet overhead, which might explain WD's claim that the FireWire interface is a little faster.
My experience with Firewire has not been all that good. I figured that since Apple had been using it for years, and it is an IEEE standard, that Firewire would be more reliable than USB. I was also a bit wary as the USB disk drivers on SuSE gave warning messages saying they might not be very reliable.
I first used Firewire external drives in 2003 on whatever was the current version of SuSE Pro at the time, and on a FreeBSD 4.8 system, and have Firewire drives on several SuSE systems up to SuSE Linux Enterprise 10.
The FreeBSD machine has never shown any problems with its FW drive, but the SuSE systems often seem to stop talking to the drive for no apparent reason.
At this time, most of our Linux boxes are running USB 2.0, and the external Firewire-only drives are all on our Macs which seem to have far better FW support than Linux.
Bill
On Wed, Aug 13, 2008 at 18:43, Bill Campbell centos@celestial.com wrote:
My experience with Firewire has not been all that good. I figured that since Apple had been using it for years, and it is an IEEE standard, that Firewire would be more reliable than USB. I was also a bit wary as the USB disk drivers on SuSE gave warning messages saying they might not be very reliable.
Same here. I just migrated our backups from Firewire 800 to USB2, because the Firewire was causing us a kernel crash per week and we were having to reboot our server because of the backup drives. This on three different machines, one running SuSE 10 and two others with CentOS 5 with the centosplus kernel.
The situation got out of control one month ago, when we had one machine with 3 crashes on the same week. I migrated its backup to USB2, and I've been running stable ever since. Firewire never again.
We bought an eSATA drive and and eSATA external card, but we still haven't put it to work. Eventually I plan to move to eSATA to get more speed, but meanwhile, I'll stick with USB2, whose performance is not spectacular, but enough for my backups for now.
HTH, Filipe
On Fri, Aug 15, 2008 at 8:56 AM, Filipe Brandenburger filbranden@gmail.comwrote:
On Wed, Aug 13, 2008 at 18:43, Bill Campbell centos@celestial.com wrote:
My experience with Firewire has not been all that good. I figured that since Apple had been using it for years, and it is an IEEE standard, that Firewire would be more reliable than USB. I was also a bit wary as the
USB
disk drivers on SuSE gave warning messages saying they might not be very reliable.
Same here. I just migrated our backups from Firewire 800 to USB2, because the Firewire was causing us a kernel crash per week and we were having to reboot our server because of the backup drives. This on three different machines, one running SuSE 10 and two others with CentOS 5 with the centosplus kernel.
I haven't had any problem with the machine since the FW drive was plugged in and left plugged in since I have not been physically back on location. What causes this crash and how would I know it is related to FW or not, in the event but hopefully never, the system does crash?
Am 17.08.2008 um 17:42 schrieb Noob Centos Admin:
On Fri, Aug 15, 2008 at 8:56 AM, Filipe Brandenburger <filbranden@gmail.com
wrote:
On Wed, Aug 13, 2008 at 18:43, Bill Campbell centos@celestial.com wrote:
My experience with Firewire has not been all that good. I figured
that
since Apple had been using it for years, and it is an IEEE
standard, that
Firewire would be more reliable than USB. I was also a bit wary
as the USB
disk drivers on SuSE gave warning messages saying they might not
be very
reliable.
Same here. I just migrated our backups from Firewire 800 to USB2, because the Firewire was causing us a kernel crash per week and we were having to reboot our server because of the backup drives. This on three different machines, one running SuSE 10 and two others with CentOS 5 with the centosplus kernel.
I haven't had any problem with the machine since the FW drive was plugged in and left plugged in since I have not been physically back on location. What causes this crash and how would I know it is related to FW or not, in the event but hopefully never, the system does crash?
Some drivers don't seem to cope very well with the spurious bus-resets and disconnects that seem to plague most firewire drives. I once had to move 750 GB to two FW drives because I had to rebuild a SATA2-RAID on a different controller. At that time, my FreeBSD6.2 notebook (with Firewire on board) even seemed a bit faster (with USB2) than the SLES9 server (Dual Precott Xeons) with Firewire 800. But FreeBSD also crashed from time to time, though it seemed to handle bus-resets and link-losses a bit better. Getting a card that was supported on SLES was funny anyway - SuSE would not recommend a card to buy, because nobody knows which cards contain which chips. If it doesn't work, buy another one. Repeat until it works....
More recently, a 1 TB WD "MyBook" (USB) just died in the process of moving 700 GB of files on it. Moral of the story: - Firewire is cool (I _love_ the target-mode in my Macs), but the implementation sucks most of the the time. - USB2.0 doesn't suck much less. It's just used more widely and obvious bugs show up often enough so that they might get fixed (in a revision of the hardware you don't own...) - in my book, USB means "Useless Serial Bus" - because it's obviously not suited for much more than keyboards, mice and the occasional camera)
Rainer
on 8-13-2008 2:30 PM Kenneth Porter spake the following:
On Wednesday, August 13, 2008 5:28 PM +0800 Noob Centos Admin centos.admin@gmail.com wrote:
ieee1394: Node 0-00:1023: Max speed [S400] - Max payload [2048]
S400 is 400 megabits, while USB 2 is 480 megabits. Firewire has less packet overhead, which might explain WD's claim that the FireWire interface is a little faster.
And isn't firewire DMA capable while USB is PIO?
--On Wednesday, August 13, 2008 4:31 PM -0700 Scott Silva ssilva@sgvwater.com wrote:
And isn't firewire DMA capable while USB is PIO?
You can read the controller spec here: