Hi Everyone:

I'm having a weird problem for the second time, so I don't think it's a casuality...


When I do a "big" data write (200mb or more) to my ext3 partition, it "crashes" giving me "input/output error" with every command I try.

Last time it happened, the partition had several errors but fsck couldn't fix it. I had to re-format the partition.
This time, it shows no errors (yet...?) and every time I reboot, everything gets back to normal. But I can't write data because it would crash again, and sooner or later, the errors will appear again I suppose.

My root partition is also an ext3 but that one works fine.
However, the problem didn't appeared again instantly: I've been writing things for a while until it crashed again, so the root partition could present the same problem if I do constants writings.

The disk itself is not the problem as it is new and works fine in another computer.


BTW, I was using Zenwalk 4.8 and upgraded the whole system (except for aaa_base, kernel, kernelsource and ndiswrapper)... so, except for those packages, it's a Zenwalk 5.0


Thanks in advance...

Sounds like a disk problem to me. Probably faulty hardware.

not sure: I've scanned the disk with HDD Regenerator and some other soft from a Hiren's Boot CD and I found nothing... =S

How big is the partition, and what command are you using (including options) to format the disk?

Once the error occurs, can you unmount it and remount it, and then write to it??

it's a 60gb partition and no, I can't umount it and mount it again because once the error occurs the whole system stops working: every command I try turns into a "input/output error" message.

I used "mkfs.ext3 /dev/xxx" to format the partition. No options.
Maybe I'll try XFS and see how that one goes.

I'm thinking there is an incompatibility with the kernel and either the drive or the controller. When you get up to certain sizes of transfers, I think the kernel uses different types of IO access, and if there are problems, the driver essentially shuts down.

Find everything you can about the hardware disk controller and drive model with respect to Linux hardware compatibility lists. Also, there's a way to disable dma transfer from the kernel at boot time (via grub or lilo bootloaders). Disabling dma transfer might allow you to determine if the problem is that for sure. However, the disk performance will be noticeably slower.

Keep us up-to-date on your progress, please.

Ok, I'll check that when I get back to home...

Altough, if that's the case, I don't understand why it worked fine for a month after the last format... it should have failed the first week =S

anyway... thanks for the reply!