Hello all.
1. Background:
I've abandoned Windows about 6 months ago when it reboots my machine right when it loads mup.sys, after I experienced the same problem and re-installed the OS for like a dozen times.
At that time I bought new disks (SATA based) and build my Debian system. The original Windows disks are disabled in BIOS.
Now as I feel comfortable using Debian, I enabled the Windows disk (IDE based) in BIOS and tried to mount it.
I planned to move all important files from the Windows disk to my SATA Linux disks, then I'd re-partition the Windows disk and make some use of the disk.
** A lot of filenames are Chinese, named and created in Windows.
Since the last time I used Windows was like 6 months ago. I lost track of whether I used NTFS or FAT32 as partition type.
2. What I did:
Using fdisk on hdb (hda was a CD-ROM), I found hdb1 and hdb5 to be logical paritions.
hdb1 was my former C:, and hdb5 was my D:
I found the partition type of both being fat32 by using "mount /dev/hdb1 /mnt" and checking "mount" output
I was able to access hdb1 without any problem.
However, all my important data are in hdb5, so I used the mount hdb5 using "mount -t vfat -o iocharset=utf8 -o noatime /dev/hdb5 /mnt"
3. Problem:
"ls" showed some output fairly quick.
But as I used "ls -al", the command was very sluggish. I noticed that the CPU was heavily utilized by this command and my HDD LED on my front panel are flashing like X'Mas trees.
Then, a large number of error blocks like this are logged in dmesg:
Code:
hdb: task_in_intr: status=0x59 { DriveReady SeekComplete DataRequest Error }
hdb: task_in_intr: error=0x04 { DriveStatusError }
ide: failed opcode was: unknown
The "ls -al" command does return with correct file/dir list, but it took like 2-3 minutes to list those around 10 files/dirs in /mnt.
Then sub-dirs showed exactly the same symptom. Meaning it tooks around 3 minutes just to do an "ls -al" for every dir.
4. To make things worse:
Naturally I unmounted /mnt then ran dosfsck on /dev/hdb5. I was too rash and used this "dosfsck -rvw /dev/hdb5".
The first time I ran it, the output conatins lines like this:
Code:
/Fonts
Contains a free cluster (1245242). Assuming EOF.
and ends with this:
Code:
Read 32 bytes at 58000979968:Input/output error
So I did it again and ran "dosfsck -rvw /dev/hdb5".
This time the "Contains a free cluster" lines are changed to these:
Code:
/Fonts
Start does point to root directory. Deleting dir.
Then I knew I was did the wrong thing.
It still ends with "Read 32 bytes at 58000979968:Input/output error".
I, terrorized, mounted hdb5 using "mount -t vfat -o ro -o iocharset=utf8 -o noatime /dev/hdb5 /mnt"
Executed "ls -al", then after 3 minutes, the dirs reported in fsck are really gone....
I was very very very fortunate that none of my important files are deleted in the above process. But I still need to browse the dir tree to get my files, waiting 3 minutes in every sub-dir is almost infeasible as there's thousands of them.
I noticed that when I have waited 3 minutes and got a successful "ls -al" output, then without umount/remounting hdb5, subsequent execution of "ls -al" on the same dir is fast like normal operations.
5. My question:
Fairly simple, why did this slow response and I/O error thing happened?
And, is there any way to work around this and get my files home on Linux partitions?
Thank you for all your kindness to crunch through my lenthy post.
Many thanks for any advice or assistance offered.
==
Edit:
Forgot to mention my system spec:
Kernel: 2.6.11-cko4 (with vfat and ntfs support compiled as modules)
Distro: Debian Sarge
Windows disk: ATA disk sitting on IDE0 slave (IDE0 master was a CDROM)
