I had someone plug in a brand new 4TB drive via usb in an external enclosure in a data centre. I remotely used disk to create a partition with the default parameters to use up the entire drive. I then ran mkfs.ext4. After copying lots of data, I had the drive shipped to me.
When plugged in on the computer at home (via SATA internally). I can't mount the drive.
I'm getting the wrong fs type, bad superblock error that you see many questions about. The difference is that I know I did format it with ext4.
I did see one question that mentioned something about the partition starting too early. Here is my fdisk -l output:
Disk /dev/sda: 4000.8 GB, 4000787030016 bytes
42 heads, 63 sectors/track, 2953150 cylinders, total 7814037168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk identifier: 0xfb4c8856
Device Boot Start End Blocks Id System
/dev/sda1 256 976754645 488377195 83 Linux
Is there something I can do to avoid losing the data? Or do I have to ship it back, start over, and ship it back to me once again?
Is there something I can do to avoid losing the data?
Yes. You can access the data after mounting like this:
mount -o ro,offset=((256*4096)) /dev/sda /path/to/mountpoint
(ro just in case; if files look right, you can remount with -o rw).
This answer explains what happened:
The enclosure exposes the drive to the computer as an Advanced Format 4Kn device, allowing the use of MBR for compatibility with Windows XP systems. When the drive is removed from the enclosure, the change in logical sector format results in an invalid partition table.
Your drive now reports the capacity of 7814037168 logical sectors of 512 bytes each. When in the enclosure, it was 976754646 logical sectors of 4096 bytes each.
The current partition entry was valid in terms of 4096-byte sectors. It says the partition spans from the sector number 256 to 976754645, which was the last sector (keep in mind sectors are numbered from 0; N sectors take numbers from 0 to N-1).
And I can tell this is a MBR (DOS) partition table. GPT needs few sectors at the end of the device for its backup table. You had no unused sectors there, so MBR
But now any tool sees the device with 512-byte logical sectors. The partition table again says the only partition spans from the sector number 256 to 976754645 and this is wrong.
The proper values now are:
Note the latter is the very last sector (your fdisk says there are 7814037168 sectors).
You cannot fix the MBR partition table because now it should take too many sectors. Compare what Wiki says:
Since block addresses and sizes are stored in the partition table of an MBR using 32 bits, the maximal size, as well as the highest start address, of a partition using drives that have 512-byte sectors (actual or emulated) cannot exceed 2 TiB−512 bytes (2,199,023,255,040 bytes or 4,294,967,295 sectors × 512 bytes per sector). Alleviating this capacity limitation was one of the prime motivations for the development of the GPT.
It would not be easy to fully convert to GPT, because you have no room for the secondary (backup) partition table at the end of the device. MBR lives at the beginning of the device only; GPT requires room at the beginning and at the end.
Still you can tell mount at what offset the filesystem starts, this is what my command does. The offset is 256*4096 bytes (or 2048*512 bytes, it's the same number). The command given above uses the shell to calculate the offset. The offset counts from the beginning of the entire device, therefore the command uses /dev/sda, not /dev/sda1.
My tests indicate ext4 doesn't rely on the logical sector size of the underlying device, so you should be OK mounting this way.
Now it should be clear that "shipping it back, starting over, and shipping it back once again" wouldn't help. The enclosure would translate the logical sector size again and you would be surprised the filesystem mounts. On the other hand if you clear the disk now, create a GPT partition table and a filesystem anew, and then ship the drive, it won't mount in the data centre, if they connect it via the same enclosure.
If you need to ship the disk back and forth, consider a superfloppy, i.e. a filesystem on the entire device, without any partition table (e.g. mkfs.ext4 /dev/sda). You mount such filesystem with mount /dev/sda /path/to/mountpoint regardless of whether there is an enclosure that interferes or not.
Collected from the Internet
Please contact [email protected] to delete if infringement.
Comments