Re: [SLUG] recover NTFS

From: steve szmidt (steve@szmidt.org)
Date: Mon Feb 20 2006 - 02:35:13 EST


On Sunday 19 February 2006 16:21, Eben King wrote:
> So my friend D brought me a dead USB HD. 160 GB, about half full (he
> said). XP hemmed and hawed when the drive was plugged in and wouldn't show
> its contents. So I popped it on my box (Linux, natch) and got 67 GiB of
> files from it, in several big tar files. Yay Linux. Took over two days,
> because every time there was an error, it stopped and waited (for what?

It was having access problems. (Checksum errors.) So it would reread over and
over.

> The error to fix itself?) for 5.5 minutes (I timed it). Boo Linux.

Linux Boo!? It's probably h/w or user problem.

> Now I've got everything I can get, and it's time to put it back. NTFS
> writing is unreliable and new, so I chose FAT (vfat). Had to make 3
> primary + virtual partitions, as XP's formatter won't make a 128 GiB FAT
> partition (W98's will, but I can't get the drive to show up in W98).

Ah, still using w98... OK, that's a problem in itself. I'd strongly recommend
moving up to W2K SP2. This is how far you can go without getting into the
EULA where you agree to let MS into your computer.

Now you have a far more reliable and faster system. NTFS smokes FAT and is not
unreliable under windows.

Hmm. My experience is that NTFS (under Linux file system driver) is working
fine. It is not exactly new as that has been in progress for years now. It's
being considered experimental but I have had zero problems over the last
couple of years.

After a while using FAT you will wish you did. Never mind trying to repair it.

> Copying to vfat is VERY slow -- in 6.5 hours it's written 11.3 GiB, which
> is about 500 KiB/s. That's from an uncompressed tar file. It's slower on
> big files, pausing for many seconds in the write.

BTW, It's commonly written as KB and GB.

> What can I do to speed this up? I have half a mind to create a big file,
> format it ext[23], loopback mount it, extract the tar files to it, export
> it via Samba, mount it from an XP laptop over wifi, and restore it THAT
> way. I'm afraid that's more trouble than it's worth.
>
> Also, my load went way up:
>
> eben@pc:/mnt/temp2$ uptime
> 16:15:31 up 3 days, 16:43, 9 users, load average: 10.70, 10.72, 10.74
>
> procs -----------memory---------- ---swap-- -----io---- --system--
> ----cpu---- r b swpd free buff cache si so bi bo in
> cs us sy id wa 0 10 2828 12236 6456 635788 0 0 131 118 109
> 12 5 4 33 57 0 10 2828 12232 6476 635664 0 0 359 194
> 1358 3928 2 2 0 96 0 10 2828 12092 6472 635732 0 0 154
> 176 1362 3874 1 3 0 96 0 10 2828 12436 6444 635704 0 0 231
> 177 1347 3835 1 2 0 96 1 10 2828 12116 6468 635724 0 0
> 590 176 1396 3914 2 3 0 95
>
> How do I find out what those "waiting" processes are? Can I convince "ps"
> to tell me?

Waiting is normal, commands are queued. Executing a command like:
ps -eo pid,tid,class,rtprio,ni,pri,psr,pcpu,stat,wchan:14,comm

will tell you more of what is going on. Be prepared to use the man page!

-- 

Steve Szmidt

"For evil to triumph all that is needed is for good men to do nothing. Edmund Burke ----------------------------------------------------------------------- This list is provided as an unmoderated internet service by Networked Knowledge Systems (NKS). Views and opinions expressed in messages posted are those of the author and do not necessarily reflect the official policy or position of NKS or any of its employees.



This archive was generated by hypermail 2.1.3 : Fri Aug 01 2014 - 18:35:55 EDT