Dear NTFS-3g team,

Apologies if I shouldn't be writing here. Please refer me elsewhere if I am
in wrong place.

I would really appreciate some guidance on how to proceed under my current
circumstance..

I needed to make some room on an NTFS storage partition. This was a 2TB
storage media disk, so I used parted to shrink a preceding ext4 partition,
before attempting to grow the second, NTFS partition.

While resizing the ntfs partition, parted stalled, all hard disk activity
ceased, and I found some nasty looking errors messages in the kernel log:

...
Jun 22 15:03:45 metabuntu kernel: cdb[0]=0x28: 28 00 e5 e4 1d 19 00 00 08
00
Jun 22 15:03:45 metabuntu kernel: sd 0:0:1:0: [sdg] Unhandled error code
Jun 22 15:03:45 metabuntu kernel: Result: hostbyte=0x04 driverbyte=0x00
Jun 22 15:03:45 metabuntu kernel: Buffer I/O error on device sdg2, logical
block 466756879
...


Back in the parted window, all widgets and scrollbars had frozen, but I
could
maximise the kde window frame, to see more of the command logs. The last
command that had run - and the one that had failed - was ntfsresize.
Resizing the ext4 partition had completed successfully; I can mount the
ext4
partition, seemingly without problem..

I noticed in the parted log, that one of the ntfs-3g tools had recommended
to do a dry run of ntfs-resize, first. Well, parted didn't do that; it just
went ahead and resized the partition. The partition was 92% full, which
can't have helped; I should have known better...

The partition table, after the ntfs-resize command, now looks like this:-

$ sudo fdisk -l -u /dev/sdh

Disk /dev/sdh: 2000.4 GB, 2000398934016 bytes, 3907029168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk label type: dos
Disk identifier: 0x442e72b8

        Device Boot      Start         End      Blocks   Id  System
/dev/sdh1            2048   122881184    61439568+  83  Linux
/dev/sdh2       122881185  3907024064  1892071440    7  HPFS/NTFS/exFAT

----

The overall operation I was attempting to perform, was basically:-

partition 1 - ext4 -  600 GB ->   60GB
partition 2 - ntfs - 1200 GB -> 1740GB

I foolishly didn't create any backups in between resize operations, but
I could see and copy the initial start and end sector locations, from
parted's log window.

In sectors, the initial ntfs partition sector locations were:
Start: 1,351,682,048
End:   3,907,024,064

With this information I can find the old partition data and mount the NTFS
partition using a loop device and specified offset:-

$ sudo losetup --offset 692061208576 --sizelimit 1308335112704 -f --show
/dev/sdg
/dev/loop0
$ sudo mount -t ntfs /dev/sdg /mnt
$ ls /mnt
... all my files :) ...


That looked promising, so I thought I'd unmount the drive, delete the
loopback device and use ddrescue to copy the partition from the disk.

That didn't work. At some point the hard drive failed, with a bunch of I/O
errors in dmesg's output, eventually leading to this lot:-

[Mon Jun 24 10:10:27 2013] sd 0:0:1:0: [sdg] CDB:
[Mon Jun 24 10:10:27 2013] sd 0:0:1:0: [sdg] READ CAPACITY failed
[Mon Jun 24 10:10:27 2013] sd 0:0:1:0: [sdg]
[Mon Jun 24 10:10:27 2013] Result: hostbyte=0x04 driverbyte=0x00
[Mon Jun 24 10:10:27 2013] sd 0:0:1:0: [sdg] Sense not available.
[Mon Jun 24 10:10:27 2013] cdb[0]=0x28: 28 00 50 d2 e9 c0 00 00 08 00
[Mon Jun 24 10:10:27 2013] end_request: I/O error, dev sdg, sector  
1355999680
[Mon Jun 24 10:10:27 2013] sd 0:0:1:0: [sdg] Unhandled error code
[Mon Jun 24 10:10:27 2013] sd 0:0:1:0: [sdg]
[Mon Jun 24 10:10:27 2013] Result: hostbyte=0x04 driverbyte=0x00
[Mon Jun 24 10:10:27 2013] sd 0:0:1:0: [sdg] CDB:
[Mon Jun 24 10:10:27 2013] cdb[0]=0x28: 28 00 50 d2 e9 c8 00 00 08 00
[Mon Jun 24 10:10:27 2013] end_request: I/O error, dev sdg, sector  
1355999688
[Mon Jun 24 10:10:27 2013] sd 0:0:1:0: [sdg] Asking for cache data failed
[Mon Jun 24 10:10:27 2013] sd 0:0:1:0: [sdg] Assuming drive cache: write  
through
[Mon Jun 24 10:10:27 2013] sdg: detected capacity change from  
2000398934016 to 0


It seems that when this message appears in `dmesg -T`, the hard drive
completely dies, until the machine is rebooted. Even `fdisk -l` errors  
out:-

fdisk: cannot open /dev/sdg: Invalid argument

This morning, after rebooting the machine, I repeated the losetup / mount
procedure and copied as much as possible from the hard drive, with `cp -r`.
I managed to get about 10GB of files, before an I/O error shut down the
device, so am still about 1.1TB short...

---

Please advise on how best to proceed under such circumstances?

I've dual boot Windows / Arch Linux, but am almost always booted in Linux
land these days. I did try chkdsk on the partition, but without an MFT,
chkdsk wasn't having any of it.

I bought a 3TB drive, in panic after the hard drive failed. This is to
where I'm trying to recover the data.

So, it seems a hardware failure caused ntfsresize to break. I hope that
it's localised to a specific subfolder, which I could skip in a subsequent
attempt to copy all files...
Rebooting for each attempt will get quite tedious. though...

I'm concerned that a lot of my files were moved to before the partition's
initial start location. I doubt ddrescue will look before the partition
start for lost files, and without an MFT in the new partition location,
those files are essentially lost, especially without knowledge of the
algorithm that moved them, or a program that could recover them.

I also know jack about MFT's, but thought I could use dd to transfer the
old MFT to the new MFT location, even though I'm sure they'd be different  
sizes.
Might that help at all?

Any advice on how to proceed, or where better to ask for help, would be
really appreciated!

Kind regards,
Alex

------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
ntfs-3g-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ntfs-3g-devel

Reply via email to