harddisk not recognized / filesystem too large to mount safely on this system / hdparm shows garbage

Question

I have a 4 TB Verbatim external hard disk with ext4.

It can be successfully mounted at my Raspberry Pi.

I am trying to plug it at my WD Mybook Live Duo device where I have SSH root access.

When I plug in the device, I get following dmesg messages:

usb 1-1: new high speed USB device using dwc_otg and address 2
usb 1-1: New USB device found, idVendor=18a5, idProduct=0400
usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 1-1: Product: USB 3.0 Desktop HD
usb 1-1: Manufacturer: Verbatim
usb 1-1: SerialNumber: 306239230569
usb 1-1: configuration #1 chosen from 1 choice
usbcore: registered new interface driver libusual
Initializing USB Mass Storage driver...
scsi2 : SCSI emulation for USB Mass Storage devices
usbcore: registered new interface driver usb-storage
USB Mass Storage support registered.
usb-storage: device found at 2
usb-storage: waiting for device to settle before scanning
scsi 2:0:0:0: Direct-Access     ST4000DM 000-1F2168       CC52 PQ: 0 ANSI: 6
sd 2:0:0:0: Attached scsi generic sg2 type 0
sd 2:0:0:0: [sdc] Very big device. Trying to use READ CAPACITY(16).
usb-storage: device scan complete
sd 2:0:0:0: [sdc] 7814037168 512-byte logical blocks: (4.00 TB/3.63 TiB)
sd 2:0:0:0: [sdc] Write Protect is off
sd 2:0:0:0: [sdc] Mode Sense: 1f 00 00 08
sd 2:0:0:0: [sdc] Assuming drive cache: write through
sd 2:0:0:0: [sdc] Very big device. Trying to use READ CAPACITY(16).
sd 2:0:0:0: [sdc] Assuming drive cache: write through
 sdc: sdc1
sd 2:0:0:0: [sdc] Very big device. Trying to use READ CAPACITY(16).
sd 2:0:0:0: [sdc] Assuming drive cache: write through
sd 2:0:0:0: [sdc] Attached SCSI disk

The size of 4 TB seems to be recognized correctly.

Note that the message Very big device. Trying to use READ CAPACITY(16). does not seem to be an error, since it happens at my Raspberry too, but there everything works fine.

The devices /dev/sdc and /dev/sdc1 appear. So, at least it recognizes the partition table, I guess.

(I cannot run fdisk -l since it is not installed at the device and I don't want to mess around too much on that device)

When I run mount /dev/sdc1 ./mymountpoint/ I get following error in dmesg:

EXT4-fs (sdc1): filesystem too large to mount safely on this system

hdparm -I /dev/sdc shows absolute garbage:

NAS:/DataVolume# hdparm -I /dev/sdc

/dev/sdc:
SG_IO: bad/missing sense data, sb[]:  70 00 05 00 00 00 00 0a 00 00 00 00 24 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

ATA device, with removable media
        Serial Number:      abhs¦UU
        Media Serial Num:   ¦U¦¦yYT¦UU

        Media Manufacturer:  H

        Transport:          Parallel, ATA8-APT
Standards:
        Used: unknown (minor revision code 0x5555)
        Supported: 9 7 6 5
        Likely used: 9
Configuration:
        Logical         max     current
        cylinders       21845   0
        heads           4352    0
        sectors/track   61711   0
        --
        Logical  Sector size:                   512 bytes
        Physical Sector size:                  4096 bytes
        Logical Sector-0 offset:            2796032 bytes
        device size with M = 1024*1024:  2864663189 MBytes
        device size with M = 1000*1000:  3003817068 MBytes (3003817 GB)
        cache/buffer size  = unknown
        Nominal Media Rotation Rate: 11884
Capabilities:
        IORDY(may be)(can be disabled)
        Standby timer values: spec'd by Vendor
        R/W multiple sector transfer: Max = 0   Current = ?
        Recommended acoustic management value: 18, current value: 0
        DMA: sdma15
        PIO: unknown
           *    READ BUFFER DMA command
           *    Long physical sector diagnostics
           *    CFast specification support
Security:
        Master password revision code = 112
                supported
                enabled
                locked
        not     frozen
                expired: security count
                supported: enhanced erase
        Security level high
Logical Unit WWN Device Identifier: 776f000000000013
        NAA             : 7
        IEEE OUI        : 76f000
        Unique ID       : 000000013
Integrity word not set (found 0x1400, expected 0xbaa5)

NAS:/DataVolume# lsusb shows:

Bus 001 Device 003: ID 18a5:0400 Verbatim, Ltd
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

What can I do to have the hard disk running at this system?

(I want to use it to create backups with rsync since my network is really slow)

Linux at the Raspberry:

uname --all
Linux raspberrypi 3.12.22+ #691 PREEMPT Wed Jun 18 18:29:58 BST 2014 armv6l GNU/Linux

Linux at the NAS:

uname --all
Linux NAS 2.6.32.11-svn70860 #1 Thu May 17 13:32:51 PDT 2012 ppc GNU/Linux

---

UPDATE

Here are the correct hdparm which I get from a Raspberry Pi or a Ubuntu Live CD:

desinfect@desinfect:/dev$ sudo hdparm -I /dev/sdb

/dev/sdb:

ATA device, with non-removable media
    Model Number:       ST4000DM000-1F2168                      
    Serial Number:      Z300ZT7T
    Firmware Revision:  CC52    
    Transport:          Serial, SATA 1.0a, SATA II Extensions, SATA Rev 2.5, SATA Rev 2.6, SATA Rev 3.0
Standards:
    Used: unknown (minor revision code 0x0029) 
    Supported: 8 7 6 5 
    Likely used: 8
Configuration:
    Logical     max current
    cylinders   16383   16383
    heads       16  16
    sectors/track   63  63
    --
    CHS current addressable sectors:   16514064
    LBA    user addressable sectors:  268435455
    LBA48  user addressable sectors: 7814037168
    Logical  Sector size:                   512 bytes
    Physical Sector size:                  4096 bytes
    Logical Sector-0 offset:                  0 bytes
    device size with M = 1024*1024:     3815447 MBytes
    device size with M = 1000*1000:     4000787 MBytes (4000 GB)
    cache/buffer size  = unknown
    Form Factor: 3.5 inch
    Nominal Media Rotation Rate: 5900
Capabilities:
    LBA, IORDY(can be disabled)
    Queue depth: 32
    Standby timer values: spec'd by Standard, no device specific minimum
    R/W multiple sector transfer: Max = 16  Current = ?
    Advanced power management level: 128
    Recommended acoustic management value: 208, current value: 0
    DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 udma5 *udma6 
         Cycle time: min=120ns recommended=120ns
    PIO: pio0 pio1 pio2 pio3 pio4 
         Cycle time: no flow control=120ns  IORDY flow control=120ns
Commands/features:
    Enabled Supported:
       *    SMART feature set
            Security Mode feature set
       *    Power Management feature set
       *    Write cache
       *    Look-ahead
       *    Host Protected Area feature set
       *    WRITE_BUFFER command
       *    READ_BUFFER command
       *    DOWNLOAD_MICROCODE
       *    Advanced Power Management feature set
            Power-Up In Standby feature set
       *    SET_FEATURES required to spinup after power up
            SET_MAX security extension
       *    48-bit Address feature set
       *    Device Configuration Overlay feature set
       *    Mandatory FLUSH_CACHE
       *    FLUSH_CACHE_EXT
       *    SMART error logging
       *    SMART self-test
       *    General Purpose Logging feature set
       *    WRITE_{DMA|MULTIPLE}_FUA_EXT
       *    64-bit World wide name
            Write-Read-Verify feature set
       *    WRITE_UNCORRECTABLE_EXT command
       *    {READ,WRITE}_DMA_EXT_GPL commands
       *    Segmented DOWNLOAD_MICROCODE
       *    Gen1 signaling speed (1.5Gb/s)
       *    Gen2 signaling speed (3.0Gb/s)
       *    Gen3 signaling speed (6.0Gb/s)
       *    Native Command Queueing (NCQ)
       *    Phy event counters
       *    unknown 76[15]
            DMA Setup Auto-Activate optimization
            Device-initiated interface power management
       *    Software settings preservation
       *    SMART Command Transport (SCT) feature set
       *    SCT LBA Segment Access (AC2)
            unknown 206[7]
            unknown 206[12] (vendor specific)
Security: 
    Master password revision code = 65534
        supported
    not enabled
    not locked
    not frozen
    not expired: security count
        supported: enhanced erase
    508min for SECURITY ERASE UNIT. 508min for ENHANCED SECURITY ERASE UNIT.
Logical Unit WWN Device Identifier: 5000c500651cc162
    NAA     : 5
    IEEE OUI    : 000c50
    Unique ID   : 0651cc162
Checksum: correct


desinfect@desinfect:/dev$ sudo fdisk -l /dev/sdb

Warnung: GPT (GUID-Partitionstabelle) auf '/dev/sdb' erkannt! Das Hilfsprogramm Fdisk unterstützt GPT nicht. Verwenden Sie GNU Parted.


Disk /dev/sdb: 4000.8 GB, 4000787030016 bytes
255 Köpfe, 63 Sektoren/Spur, 486401 Zylinder, zusammen 7814037168 Sektoren
Einheiten = Sektoren von 1 × 512 = 512 Bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Festplattenidentifikation: 0x7453181c

   Gerät  boot.     Anfang        Ende     Blöcke   Id  System
/dev/sdb1               1  4294967295  2147483647+  ee  GPT

The hard disk has GPT. gparted shows a 4 MB unpartitioned area and the rest of 3.6 TB are used for an ext4 partition. parted does show it as:

$ parted --list

Modell: ST4000DM 000-1F2168 (scsi)
Festplatte  /dev/sdb:  4001GB
Sektorgröße (logisch/physisch): 512B/512B
Partitionstabelle: gpt

Nummer  Anfang  Ende    Größe   Dateisystem  Name   Flags
 1      4194kB  4001GB  4001GB  ext4         linux

The NAS does use 2x 4 TB hard disks which are mirrored using mdraid . I wonder why the NAS has no problem using them...

Solution

You can't do fdisk because you're already at twice MBR's maximum with a 4TB device at 512b sectors. You need to format it with GPT.

From wikipedia:

The organization of the partition table in the MBR limits the maximum addressable storage space of a disk to 2 TB (232 × 512 bytes).

Get the gdisk package and reformat the disk (though it seems to me it should already be). If you're looking at that disk from a machine that cannot mount a GPT disk then the protective MBR would explain the garbled hdparm.

Else I see the physical sector size is listed at 4kb - which makes a little more sense - and makes the MBR feasible, but, as you have seen, rather unwieldy. The solution is going to lie in an updated partition table.

More from wikipedia

Since partitioning information is stored in the MBR partition table using a beginning block address and a length, it may in theory be possible to define partitions in such a way that the allocated space for a disk with 512-byte sectors gives a total size approaching 4 TB, if all but one partition are located below the 2 TB limit and the last one is assigned as starting at or close to block 232−1 and specify the size as up to 232−1, thereby defining a partition which requires 33 rather than 32 bits for the sector address to be accessed. However, in practice, only certain LBA-48 enabled operating systems, including Linux, FreeBSD and Windows 7 that use 64-bit sector addresses internally actually support this.

Due to code space constraints and the nature of the MBR partition table to only support 32 bits, boot sectors, even if enabled to support LBA-48 rather than LBA-28, often use 32-bit calculations, unless they are specifically designed to support the full address range of LBA-48 or are intended to run on 64-bit platforms only. Any boot code or operating system using 32-bit sector addresses internally would cause addresses to wrap around accessing this partition and thereby result in serious data corruption over all partitions.

For disks that present a sector size other than 512 bytes, such as USB external drives, there are limitations as well. A sector size of 4,096 results in an eight-fold increase in the size of a partition that can be defined using MBR, allowing partitions up to 16 TiB (232 × 4096 bytes) in size. Versions of Windows more recent than Windows XP support the larger sector sizes as well as Mac OS X, and the Linux kernel has supported larger sector sizes since 2.6.31 or 2.6.32, but issues with boot loaders, partitioning tools and computer BIOS implementations present certain limitations, since they are often hard-wired to reserve only 512 bytes for sector buffers, causing memory to become overwritten for larger sector sizes. This may cause unpredictable behaviour as well, and therefore should be avoided when compatibility and standard conformity is an issue.

There's a link there to a Western Digital .pdf discussing the possibility of using larger MBR sector sizes on very large drives. Apparently the 2.6.32 kernel was the first ever to introduce support for this feature. I am unaware if it is compile-time option or not, but it maybe it was too new when your own NAS kernel was built.

Apparently there are other possibilities. From the .pdf

Older Linux Kernel version (all 2.4 and pre‐2.6.32) computing 
environments with a legacy BIOS and MBR partition table scheme 
encounter a barrier at 2.19 TB because they can address only up 
to 232 logical blocks. Be sure to use kernels that contain support 
for drives greater than 2.19TB.  The kernels released after April 
2010 have support for large capacity drives using 4096 sector sizes.

...

How You Can Take Advantage of Large Capacity Drives in Linux
• Use fdisk from util‐linux‐ng >= 2.17.2 or parted/gparted   
• Use +size {M, G} convention to specify "Last sector" 
  (e.g. +5G to create 5GiB partition) then fdiskl aligns the 
  size to physical block boundary  
• Remember that fdisk(8) always follows your wishes ‐‐ it means 
  that if you explicitly define first/last sector number then 
  the partition could be misaligned.
• Start the extended partition at sector 64 (the default is 63), 
  and end it at sector (total amount of sectors on the drive – 1)

Comments

[Daniel Marschall]

No, I can't use fdisk because the NAS is a minimal system without that tool. The external hard disk is already partitioned and works fine on every other linux box. I do not want to change the partitions. As I said, hdparm shows completely garbage. All information are false! Like the binary garbage "Serial Number: abhs¦UU Media Serial Num: ¦U¦¦yYT¦UU". On the raspberry pi the hdparm information are correct. Nothing is locked.

[mikeserv]

@rinntech - here's somebody who did use fdisk on the 4tb drive - note the warning there. It's gotta be GPT already and so probably the NAS kernel only supports MBR for some reason? Oh - the 2.6 kernel makes for a good one...

[Daniel Marschall]

Thank you very much for this idea. I have now checked the external hard disk again with a live CD and found out that it is indeed a GPT partitioned drive. Also, I posted the expected hdparm results in my question above. The question is, if it is possible to use this external harddisk at my NAS and why it is failing. I am not sure if the NAS' linux simply doesn't understand GPT at all. The NAS itself uses 2x 4 TB hard disks (I think SATA) which are mirrored using mdraid. I am not 100% sure if it is GPT too, but I think so, because it is 4 TB. So, the NAS should be able to use GPT, shouldn't it?

[Daniel Marschall]

Could it have something to do with the fact that external USB hard drives are internally handled as SCSI drives, which may have a different set of instructions? I just heared that and I found the entry Attached SCSI disk in the dmesg log. But I have no knowledge if this could be a plausible reason or not.

[mikeserv]

@rinntech - the NAS hard disks should also be GPT, I expect. You can check them, even if you can't do it at the NAS. Do like... cd /tmp; ssh root@NAS 'dd count=1024 bs=4096 if=/dev/sda' >ptable; wipefs ptable from an up-to-date Linux host. It will read PMBR for a GPT disk. Given that info I might be able to help more.

[Daniel Marschall]

Thank you very much for trying to help me. I have executed the commands you described. wipefs did not output anything and the exitcode $? was 0. If you want to have the produced file, it is here: viathinksoft.de/~daniel-marschall/temp/ptable.zip . Am I correct that it is GPT, since wipefs didn't output a warning about "DOS headers" (like it was in one of my VMs)?