** Changed in: linux (Ubuntu)
Status: Confirmed => Invalid
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/64914
Title:
e2fsck / linux kernel chokes on I/O errors
--
ubuntu-bugs mailing list
The Ubuntu Kernel Team is planning to move to the 2.6.27 kernel for the
upcoming Intrepid Ibex 8.10 release. As a result, the kernel team would
appreciate it if you could please test this newer 2.6.27 Ubuntu kernel.
There are one of two ways you should be able to test:
1) If you are comfortable
This appears to be a minor, long standing issue from upstream that
someone might want to look into at some stage...
** Changed in: linux (Ubuntu)
Sourcepackagename: e2fsprogs => linux
Assignee: (unassigned) => Ubuntu Kernel Team (ubuntu-kernel-team)
Status: Incomplete => Confirmed
--
Nice, that might be useful to know. Thank you.
(It is, of course, in the nature of "e2fsck -c" to be persistent (unlike
"cp" and "dd" which would simply fail). It seemed as if there was a
larger cluster of bad blocks, originally, AFAICT. I wonder whether the
occurrence would've been different had
Note that in the latest hdparm there is an option to set (and unset) a
block as being bad, which is a great way of replicating the problem
under controlled circumstances.
--
e2fsck / linux kernel chokes on I/O errors
https://bugs.launchpad.net/bugs/64914
You received this bug notification because
Theodore Ts'o: I just caught a slight detail. I don't know if it makes a
difference, but I'll make a note in case it does.
You wrote:
"For most (although admittedly not all) write errors, by the time the disk as
returned an error, it has retried it a few times."
...specifically speaking of WRITE
Well, it's not a e2fsprogs bug, but a kernel problem. So you could
refile this as a kernel problem, even though it's been around for over
ten years.
--
e2fsck / linux kernel chokes on I/O errors
https://bugs.launchpad.net/bugs/64914
You received this bug notification because you are a member
I was using Breezy at the time, and I've since upgraded to Dapper (which
is up-to-date), so the output of those commands now is probably useless.
I used the standard (K)ubuntu kernel, apparently version 2.6.12-9 at the
time. (I've switched a new drive as hda, on which Dapper resides, and
I've the
Make that 2.6.12-9-386, to be exact.
--
e2fsck / linux kernel chokes on I/O errors
https://bugs.launchpad.net/bugs/64914
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://li
kko: Thanks for the extra info. Can you also provide the version of
Ubuntu you we using, plus the output of the following commands as
attached files:
uname -a > uname-a.log
cat /proc/version_signature > version.log
Ill then re assign this bug to the correct version of the kernel, and
** Attachment added: "hdparmhdb.log"
http://launchpadlibrarian.net/15173538/hdparmhdb.log
--
e2fsck / linux kernel chokes on I/O errors
https://bugs.launchpad.net/bugs/64914
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-
Chris Cook: Thank you for looking into this.
The drive is, as said, currently in perfect working order. After I read
that a modern harddrive "will assign backup sectors to replace broken
ones" when you try to write data on the damaged sectors, I utilised this
fact and filled the partition in quest
** Attachment added: "lspciv.log"
http://launchpadlibrarian.net/15173559/lspciv.log
--
e2fsck / linux kernel chokes on I/O errors
https://bugs.launchpad.net/bugs/64914
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs m
** Attachment added: "lspci.log"
http://launchpadlibrarian.net/15173553/lspci.log
--
e2fsck / linux kernel chokes on I/O errors
https://bugs.launchpad.net/bugs/64914
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mai
This is actually a long-standing kernel problem. What you are seeing is
that the kernel is retrying too many times in the face of I/O errors.
For most (although admittedly not all) write errors, by the time the
disk as returned an error, it has retried it a few times. Depending on
the device driv
Thank you for reporting this issue. Please could you update us on your
situation - is this still a problem for you?
The SMART logs would be very useful, as would any information you could
provide about your hardware setup (type of interface, make/model of disk
drive and computer, etc)
If the hard
(The drive is currently working - as my number 2 drive - normally.
Writing (noncritical) data to the partition affected seems to have made,
as I hoped, the drive to assign backup sectors to replace the damaged
ones.)
--
e2fsck / linux kernel chokes on I/O errors
https://launchpad.net/bugs/64914
I think I can provide the data stored in the HDD's internal S.M.A.R.T.
logs (as accessed by 'smartctl'), from what what was probably the time
of this incident, if that would help.
--
e2fsck / linux kernel chokes on I/O errors
https://launchpad.net/bugs/64914
--
ubuntu-bugs mailing list
ubuntu-b
18 matches
Mail list logo
