I'm backing up to a NTFS partition on an external USB drive with dump. I'm seeing failures in /var/log/messages reading sector 0xFFFFFFF that cause the verify pass to fail. Are there any known problems in the USB driver?
Kernel via uname -a:
Linux segw2.mpa.lan 2.6.18-92.1.6.el5 #1 SMP Wed Jun 25 13:49:24 EDT 2008 i686 i686 i386 GNU/Linux
Message reported. (Note the number 268435455, which is 0xFFFFFFF, and occurs every time I see this happen. But a subsequent attempt to read this region with dd succeeds, so it appears to be intermittent, or dependent on some other precondition.)
Sep 7 10:48:39 segw2 kernel: sd 5:0:0:0: Device not ready: <6>: Current: sense key: Not Ready Sep 7 10:48:39 segw2 kernel: Add. Sense: Logical unit not ready, cause not reportable Sep 7 10:48:39 segw2 kernel: Sep 7 10:48:39 segw2 kernel: end_request: I/O error, dev sdb, sector 268435455 Sep 7 10:48:39 segw2 kernel: Buffer I/O error on device sdb1, logical block 33554424 Sep 7 10:48:39 segw2 kernel: sd 5:0:0:0: Device not ready: <6>: Current: sense key: Not Ready Sep 7 10:48:39 segw2 kernel: Add. Sense: Logical unit not ready, cause not reportable Sep 7 10:48:39 segw2 kernel: Sep 7 10:48:39 segw2 kernel: end_request: I/O error, dev sdb, sector 268435455 Sep 7 10:48:39 segw2 kernel: Buffer I/O error on device sdb1, logical block 33554424
on 9-7-2008 10:53 PM Kenneth Porter spake the following:
I'm backing up to a NTFS partition on an external USB drive with dump. I'm seeing failures in /var/log/messages reading sector 0xFFFFFFF that cause the verify pass to fail. Are there any known problems in the USB driver?
Kernel via uname -a:
<snip> This isn't paid 24x7 support! You need to wait more than a few hours before you re-pound (I mean resend) your message.
More than likely it is a problem with the Linux reverse engineered support for a Windows proprietary file system. Why back up to NTFS?
--On Monday, September 08, 2008 10:50 AM -0700 Scott Silva ssilva@sgvwater.com wrote:
This isn't paid 24x7 support! You need to wait more than a few hours before you re-pound (I mean resend) your message.
Sorry about the resend. I was having mail server problems this weekend and was afraid the first message had gotten lost in the outage. I didn't want to wait 24 hours to learn that it never made it through. It certainly wasn't my intent to sound insistent.
More than likely it is a problem with the Linux reverse engineered support for a Windows proprietary file system. Why back up to NTFS?
Originally I was backing up across the LAN to the drive attached to my XP workstation.
<snip>
More than likely it is a problem with the Linux reverse engineered support for a Windows proprietary file system. Why back up to NTFS?
Originally I was backing up across the LAN to the drive attached to my XP workstation.
That would isolate the error if it was caused by the NTFS driver. I would use a linux supported filesystem unless you *need* to be able to look at these dump files from a windows workstation. Also see if the Manu. has a test program to verify the drives. Sometimes a few of the PATA to USB interfaces do some strange things to I/O streams. I have a drive that would consistently lock my old XP workstations USB interfaces, but works fine on the new one.
On Mon, 2008-09-08 at 12:12 -0700, Scott Silva wrote:
<snip> >><snip>
Sometimes a few of the PATA to USB interfaces do some strange things to I/O streams. I have a drive that would consistently lock my old XP workstations USB interfaces, but works fine on the new one.
Although I don't *think* this is related, can't tell. I have some new Tosh USB drives that I used to serve ISO images for CentOS on my 4.6 Centos. If I let them run overnight, they would lock the system.
I moved them to the fully updated 5.2 CentOS and the problem disappeared.
If you have a 5.2 that is not fully updated (kernel and drivers are my guess as to potential problems), maybe there is a causal relationship there.
Also, the 4.6 has a VIA KT-400A chipset while the 5.2 has a KT880 chipset. SO two more potential areas to check there.
<snip sig stuff>
HTH
Scott Silva wrote:
<snip> >> More than likely it is a problem with the Linux reverse engineered >> support for a Windows proprietary file system. Why back up to NTFS? > > Originally I was backing up across the LAN to the drive attached to my > XP workstation. That would isolate the error if it was caused by the NTFS driver. I would use a linux supported filesystem unless you *need* to be able to look at these dump files from a windows workstation.
Could reformat the disk for ext2/3 & install ext2ifs on the windows box:
While I haven't much heavy use or testing, it's worked well for me.
--On Monday, September 08, 2008 4:04 PM -0400 Toby Bluhm tkb@midwestinstruments.com wrote:
Could reformat the disk for ext2/3 & install ext2ifs on the windows box:
Very nice, thanks!
-
Kenneth Porter -
Scott Silva -
Toby Bluhm -
William L. Maltby