Hi Alex, Alex Leach wrote: > Dear NTFS-3g team, > > Apologies if I shouldn't be writing here. Please refer me elsewhere if I am > in wrong place. >
Well, this list is intended for reporting problems with ntfs-3g or associated tools. > 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 > ... > This looks like a hardware error. > 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... > It is very strange parted did not do a dry ntfsresize. > 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 > The sdh2 partition size above is 1937GB or 1846GiB, not 1740 GB or GiB.... Anyway this is within the disk size. Note that when upsizing, the partition has to be expanded first, so sdh2 should show the target size. > 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 > This does not line up with what you showed for sdh2. Did you relocate the partition ? > 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 > Did you keep this (failed) copy available ? > 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! First keep both original disk and partial copy of partition read-only. If this is a disk going mad, use the copy as much as possible. Also do not try using chkdsk. In pathological conditions, it rebuilts the MFT, destroying very useful data. Try to get the current partition parameters, from the copy or the original partition (or even from the losetup'ed partition). ntfsinfo -fm copy-file ntfsinfo -fm /dev/sdh2 (as root) Then get a diagnosis from ntfsfix. First do a "ntfsfix --help" to make sure the option -n is available on your version. ntfsfix -n copy-file ntfsfix -n /dev/sdh2 Please post the output of the above commands. If both ntfsclone and ntfsfix fail, post a copy of the boot sector instead : dd if=copy-file of=bootsector bs=512 count=1 Il will probably later need a full metadata dump, but the above will give me a minimal view. Be sure you are using recent versions of ntfsprogs (ntfsinfo, ntfsclone, etc.) Note : with this reply you have my email address. I suggest, you reply privately. Regards Jean-Pierre ------------------------------------------------------------------------------ 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
