Hi - relatively inexperienced user here. I installed CentOS 5.2 yesterday (http install via a mirror, worked brilliantly), as well as a new Seagate 1Tb USB external HDD (from the new Xtreme line), for backup/media storage.
Using fdisk I put two primary partitions on the Seagate, /dev/sde1 and /dev/sde2 (roughly half the drive each). Then I used mkfs.ext3 on both to create ext3 filesystems on those partitions. My fstab entries look like so:
/dev/sde1 /mnt/seagate1 ext3 rw,user,noexec 0 0 /dev/sde2 /mnt/seagate2 ext3 rw,user,noexec 0 0
I copied some data onto /dev/sde1 and went to bed. This morning, I found a clump of kernel messages on the console (lightly edited from /var/log/messages):
kernel: end_request: I/O error, dev sde, sector 492896319 kernel: Buffer I/O error on device sde1, logical block 61612032 kernel: EXT3-fs error (device sde1): ext3_readdir: directory #30801921 contains a hole at offset 0 kernel: Aborting journal on device sde1. kernel: end_request: I/O error, dev sde, sector 12655 kernel: Buffer I/O error on device sde1, logical block 1574 kernel: lost page write due to I/O error on sde1 kernel: sd 3:0:0:0: Device not ready: <6>: Current: sense key: Not Ready kernel: Add. Sense: Logical unit not ready, initializing command required kernel: end_request: I/O error, dev sde, sector 63 kernel: Buffer I/O error on device sde1, logical block 0 kernel: lost page write due to I/O error on sde1 kernel: ext3_abort called. kernel: EXT3-fs error (device sde1): ext3_journal_start_sb: Detected aborted journal kernel: Remounting filesystem read-only
I can guess that I/O means Input/Output, but other than that I'm flummoxed. My fear is that the Seagate is defective. Can someone point me in a good direction? Any input would be greatly appreciated.
Guest3731 wrote:
Hi - relatively inexperienced user here. I installed CentOS 5.2 yesterday (http install via a mirror, worked brilliantly), as well as a new Seagate 1Tb USB external HDD (from the new Xtreme line), for backup/media storage. Using fdisk I put two primary partitions on the Seagate, /dev/sde1 and /dev/sde2 (roughly half the drive each). Then I used mkfs.ext3 on both to create ext3 filesystems on those partitions. My fstab entries look like so:
/dev/sde1 /mnt/seagate1 ext3 rw,user,noexec 0 0 /dev/sde2 /mnt/seagate2 ext3 rw,user,noexec 0 0
I copied some data onto /dev/sde1 and went to bed. This morning, I found a clump of kernel messages on the console (lightly edited from /var/log/messages):
kernel: end_request: I/O error, dev sde, sector 492896319 kernel: Buffer I/O error on device sde1, logical block 61612032 kernel: EXT3-fs error (device sde1): ext3_readdir: directory #30801921 contains a hole at offset 0 kernel: Aborting journal on device sde1. kernel: end_request: I/O error, dev sde, sector 12655 kernel: Buffer I/O error on device sde1, logical block 1574 kernel: lost page write due to I/O error on sde1 kernel: sd 3:0:0:0: Device not ready: <6>: Current: sense key: Not Ready kernel: Add. Sense: Logical unit not ready, initializing command required kernel: end_request: I/O error, dev sde, sector 63 kernel: Buffer I/O error on device sde1, logical block 0 kernel: lost page write due to I/O error on sde1 kernel: ext3_abort called. kernel: EXT3-fs error (device sde1): ext3_journal_start_sb: Detected aborted journal kernel: Remounting filesystem read-only
I can guess that I/O means Input/Output, but other than that I'm flummoxed. My fear is that the Seagate is defective. Can someone point me in a good direction? Any input would be greatly appreciated. _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
if you take it out and put it back again is it automatically mounted and can kernel see it when you do fdisk -l ?
partha chowdhury wrote:
Guest3731 wrote:
Hi - relatively inexperienced user here. I installed CentOS 5.2 yesterday (http install via a mirror, worked brilliantly), as well as a new Seagate 1Tb USB external HDD (from the new Xtreme line), for backup/media storage.
[snip] if you take it out and put it back again is it automatically mounted and can kernel see it when you do fdisk -l ?
Strange. I took it out and put it back again, and the kernel noticed that it was installed:
SCSI device sdf: 1963525168 512-byte hdwr sectors (100205 MB) <etc.>
And it showed up as sdf when I did fdisk -l. However, when I ran "mount," this is what appeared:
/dev/sde1 on /mnt/seagate1 type ext3 (rw,noexec,nosuid,nodev) /dev/sde2 on /mnt/seagate2 type ext3 (rw,noexec,nosuid,nodev)
So apparently it's still mounted as /dev/sde1[2], but incorrectly? Very strange.
Next, I umounted both /dev/sde1 and /dev/sde2, receiving error messages on the console about "lost page write due to I/O error on sde1 [and 2]"
I've re-plugged it, and it's been recognized as /dev/sde. I ran a "mount -a" and it's been picked up by the system.
No clue where to go from here. Thanks for your help -
On Sun, Sep 28, 2008 at 5:00 PM, partha chowdhury kira.laucas@gmail.comwrote:
Guest3731 wrote:
if you take it out and put it back again is it automatically mounted and
can kernel see it when you do fdisk -l ?
Sorry to double up on your answer like this, but is there any chance that the i/o errors are due to a bad usb cable, or usb card in the main computer? I didn't mention before that the external hdd that the seagate is replacing also reported a lot of i/o errors and kept disconnecting itself, which is why I replaced it....
Thanks for any clues...
On Sun, Sep 28, 2008 at 8:29 PM, Guest notconfusedaboutthattoday@gmail.com wrote:
Sorry to double up on your answer like this, but is there any chance that the i/o errors are due to a bad usb cable, or usb card in the main computer? I didn't mention before that the external hdd that the seagate is replacing also reported a lot of i/o errors and kept disconnecting itself, which is why I replaced it....
Have you tried using a different USB cable, and maybe a different USB controller? That would narrow down your search parameters a bit.
You can also try running Seagate's Seatools program - it is available for Linux from their web site, but you have to poke around a little to find it.
Also, have you tried any other diagnostics to see what might be the problem?
mhr
Guest wrote:
On Sun, Sep 28, 2008 at 5:00 PM, partha chowdhury <kira.laucas@gmail.com mailto:kira.laucas@gmail.com> wrote:
Guest3731 wrote: if you take it out and put it back again is it automatically mounted and can kernel see it when you do fdisk -l ?
Sorry to double up on your answer like this, but is there any chance that the i/o errors are due to a bad usb cable, or usb card in the main computer? I didn't mention before that the external hdd that the seagate is replacing also reported a lot of i/o errors and kept disconnecting itself, which is why I replaced it....
Thanks for any clues...
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
i had the same problem as yours a while back. i have tried different solutions :
1> check with different usb cable. 2> may be the hdd is going bad . run e2fsck -f <device> and see what the output is .
3> try with a different machine. 4> experiment with noacpi and noirqdebug kernel boot parameters.
Guest wrote:
Sorry to double up on your answer like this, but is there any chance that the i/o errors are due to a bad usb cable, or usb card in the main computer? I didn't mention before that the external hdd that the seagate is replacing also reported a lot of i/o errors and kept disconnecting itself, which is why I replaced it....
Perhaps the drive is spinning down without informing the OS. I recall an issue last year(?) about some USB drives not behaving properly and spinning down without informing the OS, then the OS tries to access them it gets an I/O error.
All of my 2.5" western digital external USB drives seem to behave correctly when going into power save mode, have never had an I/O error as a result of them spinning down.
nate
On Mon, Sep 29, 2008 at 9:38 AM, nate centos@linuxpowered.net wrote:
Guest wrote:
Sorry to double up on your answer like this, but is there any chance that the i/o errors are due to a bad usb cable, or usb card in the main computer? I didn't mention before that the external hdd that the seagate is replacing also reported a lot of i/o errors and kept disconnecting itself, which is why I replaced it....
Perhaps the drive is spinning down without informing the OS. I recall an issue last year(?) about some USB drives not behaving properly and spinning down without informing the OS, then the OS tries to access them it gets an I/O error.
All of my 2.5" western digital external USB drives seem to behave correctly when going into power save mode, have never had an I/O error as a result of them spinning down.
Thanks so much for these excellent suggestions, I will be pursuing all of these avenues.
My apologies as well for the html mail - if Gmail's interface can be believed, I am now sending plaintext only. Once I get past these issues, I should be switching over to qmail & Mutt on my new CentOS machine -- and the Mutt, she don't lie :-)
On Mon, Sep 29, 2008 at 9:38 AM, nate centos@linuxpowered.net wrote:
Guest wrote:
Sorry to double up on your answer like this, but is there any chance that the i/o errors are due to a bad usb cable, or usb card in the main computer? I didn't mention before that the external hdd that the seagate is replacing also reported a lot of i/o errors and kept disconnecting itself, which is why I replaced it....
Perhaps the drive is spinning down without informing the OS. I recall an issue last year(?) about some USB drives not behaving properly and spinning down without informing the OS, then the OS tries to access them it gets an I/O error.
All of my 2.5" western digital external USB drives seem to behave correctly when going into power save mode, have never had an I/O error as a result of them spinning down.
nate
Revivifying an old thread only long enough to say, somewhat unhelpfully, that all of my USB problems seem to have gone away as a result of my upgrading my kernel to 2.6.27.
Unfortunately I am not knowledgeable enough to guess why this is so, but I'm adding a conclusion to my thread as a possible clue for the archive-diver.