3TB GPT drives created on Alt-F cannot be read on Linux and vice versa when using a SATA/USB adapter

465 views
Skip to first unread message

FeebleOldMan

unread,
Aug 10, 2014, 9:43:56 AM8/10/14
to
DNS-323 Rev B1
Alt-F 0.1RC4

3TB Toshiba DT01ACA300 (with the 3.5" bug)
3TB WD Green WD30EZRX (I bought this because I thought the 3.5" bug was causing problems with Alt-F)

GPT, 8GB swap on first partition (to allow fsck to complete properly), and formatted as ext4 on the remaining disk space

I'm able to partition and format both drives on Alt-F using the web interface, as well as sgdisk from the Alt-F command line. They're both accessible via cifs/ssh/web interface while plugged into the NAS. However, if I eject them from the NAS and try to access them on another computer using a SATA to USB drive connector, both drives appear as if they are unpartitioned on Ubuntu, and undetectable on OS X.

If I recreate the partitions using GParted on Ubuntu 14.04, or repeating the same commands on sgdisk from the Ubuntu command line, I'm able to access the drives on Ubuntu 14.10 (64 bit) and a Lubuntu 12.10 (32 bit) VM, and detect them on OS X. However, they're both unreadable/unmountable on Alt-F.

My older 1TB (ext2) and 2TB (ext3) drives are accessible on Alt-F as well as on Ubuntu using the SATA to USB drive connector.

What am I doing wrong?

  sgdisk --zap-all /dev/sda
 sgdisk --set-alignment=8 --new=1:64:+8096M --typecode=1:8200 /dev/sda
 sgdisk --set-alignment=8 --new=2:0:0 --typecode=2:8300 /dev/sda
 mkswap /dev/sda1
 mkfs -t ext4 /dev/sda2


All commands complete successfully.


The following is data from the WD disk prepared using the Ubuntu command line:

Ubuntu14.04> sgdisk -p /dev/sdb

Disk /dev/sdb: 732566646 sectors, 2.7 TiB
Logical sector size: 4096 bytes
Disk identifier (GUID): 0DF8EA2F- ...
Partition table holds up to 128 entries
First usable sector is 6, last usable sector is 732566640
Partitions will be aligned on 64-sector boundaries
Total free space is 58 sectors (232.0 KiB)

Number     Start (sector)     End (sector)     Size     Code     Name
     1                64          2072639      7.9 GiB   8200
     2           2072640        732566640      2.7 TiB   8300


----------

Alt-F0.1RC4> sgdisk -p /dev/sda

Creating new GPT entries.
Disk /dev/sda: 5860533168 sectors, 2.7 TiB
Logical sector size: 512 bytes
Disk identifier (GUID): 5C9C3B84-...
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 5860533134
Partitions will be aligned on 2048-sector boundaries
Total free space is 5860533101 sectors (2.7 TiB)

Number  Start (sector)    End (sector)  Size       Code  Name

João Cardoso

unread,
Aug 10, 2014, 5:06:31 PM8/10/14
to al...@googlegroups.com


On Sunday, August 10, 2014 2:43:56 PM UTC+1, FeebleOldMan wrote:
DNS-323 Rev B1
Alt-F 0.1RC4

3TB Toshiba DT01ACA300 (with the 3.5" bug)
3TB WD Green WD30EZRX (I bought this because I thought the 3.5" bug was causing problems with Alt-F)

GPT, 8GB swap on first partition (to allow fsck to complete properly), and formatted as ext4 on the remaining disk space

I'm able to partition and format both drives on Alt-F using the web interface, as well as sgdisk from the Alt-F command line. They're both accessible via cifs/ssh/web interface while plugged into the NAS. However, if I eject them from the NAS and try to access them on another computer using a SATA to USB drive connector, both drives appear as if they are unpartitioned on Ubuntu, and undetectable on OS X.

This is a very interesting issue!
 

If I recreate the partitions using GParted on Ubuntu 14.04, or repeating the same commands on sgdisk from the Ubuntu command line, I'm able to access the drives on Ubuntu 14.10 (64 bit) and a Lubuntu 12.10 (32 bit) VM, and detect them on OS X. However, they're both unreadable/unmountable on Alt-F.

When you recreate the partitions, do you  have access to the previous disk data, or do you have to also recreate filesystems?


My older 1TB (ext2) and 2TB (ext3) drives are accessible on Alt-F as well as on Ubuntu using the SATA to USB drive connector.

But they don't use GPT, they do?
 

What am I doing wrong?

  sgdisk --zap-all /dev/sda
 sgdisk --set-alignment=8 --new=1:64:+8096M --typecode=1:8200 /dev/sda
 sgdisk --set-alignment=8 --new=2:0:0 --typecode=2:8300 /dev/sda
 mkswap /dev/sda1
 mkfs -t ext4 /dev/sda2



Everything looks OK, I think that's not your fault.
 
All commands complete successfully.


The following is data from the WD disk prepared using the Ubuntu command line:

Ubuntu14.04> sgdisk -p /dev/sdb

Disk /dev/sdb: 732566646 sectors, 2.7 TiB
Logical sector size: 4096 bytes

4KB  on a 3TB WD?

Disk identifier (GUID): 0DF8EA2F- ...
Partition table holds up to 128 entries
First usable sector is 6, last usable sector is 732566640
Partitions will be aligned on 64-sector boundaries
Total free space is 58 sectors (232.0 KiB)

Number     Start (sector)     End (sector)     Size     Code     Name
     1                64          2072639      7.9 GiB   8200
     2           2072640        732566640      2.7 TiB   8300


----------

Alt-F0.1RC4> sgdisk -p /dev/sda

But is this the same disk as above?


Creating new GPT entries.
Disk /dev/sda: 5860533168 sectors, 2.7 TiB
Logical sector size: 512 bytes

512bytes
 
Disk identifier (GUID): 5C9C3B84-...
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 5860533134
Partitions will be aligned on 2048-sector boundaries
Total free space is 5860533101 sectors (2.7 TiB)

Number  Start (sector)    End (sector)  Size       Code  Name


I think that there are two hypothesis: a sgdisk bug, or a kernel bug.
Alt-F is using sgdisk version 0.8.6

When searching for the issue cause you have to always use the same disk, from the same manufacturer/model, as different manufacturers deal with bigger than 2TB disks in potentially different ways.
WD uses the "Advanced Format" way, where the drive "lies" to the operationg system saying that it has 512bytes physical sectors, while in reality it uses 4KB sectors. It then internaly translate 512bytes sector numbers to 4KB sectors. Other manufacturer might do it differently, so you can't do some tests on one disk and extrapolate the conclusions to another disk.

Determining physical sector size

In theory, the Linux kernel should return information on the physical sector size in the /sys/block/sdX/queue/physical_block_size pseudo-file and on the logical sector size in the /sys/block/sdX/queue/logical_block_size pseudo-file, where sdX is your device's node name (normally sda, sdb, and so on). In practice, however, the physical block size information is spurious, at least for the first generation of Western Digital Advanced Format drives. Unfortunately, this means that disk utilities cannot properly detect the presence of such disks.

As a practical matter, then, you must look up your drive's specifications on the manufacturer's Web site or in other ways. The /sys/block/sdX/device/model pseudo-file holds the device's model number, so you can look there and then check with the manufacturer.

With the current first generation of Advanced Format drives, Western Digital has placed stickers on the drives advertising the fact that they are Advanced Format drives. Unfortunately, these stickers imply that only Windows XP has problems with these drives. As the above benchmark results reveal, Linux users must exercise extreme caution with these drives.

So, what does /sys/block/sdX/queue/logical_block_size and /sys/block/sdX/queue/physical_block_size tells on your 64/32 bits linux distros? always using the same disk.

From your post I think they will report 4KB logical/512bytes physical for the WD disk (and what about the Toshiba disk?), while Alt-F will report 512bytes/512bytes. sgdisk might be using the value that the kernel reports, and that *might* be the reason why the partition it generates is not recognized by the other linux boxes and vice-versa.

You can also install and use 'parted' under Alt-F and see if it recognizes any of the two (Alt-F/other linux) disk partition tables.
It is also important to report the different system software/kernel versions:

For Alt-F-0.1RC4 they are:

kernel 3.10.32 (uname -a)
sgdisk 0.8.6 (sgdisk --version)
parted 2.2 (parted --version)

Not so important:
fdisk BusyBox v1.20.2
sfdisk 3.07 (sfdisk -v)

Needless to say this is a very important inter-interoperability issue for Alt-F, as most users expect to be able to use their disks existing data in case the box has a fatal hardware malfunction, so I would appreciate your feedback.

Has anyone with 3/4TB disks this issue? Or has anyone with 3/4TB disks interchanged them between a linux box and Alt-F? either using SATA directly or through an USB adapter? All reports are needed.

Thanks.


 

FeebleOldMan

unread,
Aug 11, 2014, 1:39:02 AM8/11/14
to al...@googlegroups.com


On Monday, 11 August 2014 05:06:31 UTC+8, João Cardoso wrote:


On Sunday, August 10, 2014 2:43:56 PM UTC+1, FeebleOldMan wrote:


If I recreate the partitions using GParted on Ubuntu 14.04, or repeating the same commands on sgdisk from the Ubuntu command line, I'm able to access the drives on Ubuntu 14.10 (64 bit) and a Lubuntu 12.10 (32 bit) VM, and detect them on OS X. However, they're both unreadable/unmountable on Alt-F.

When you recreate the partitions, do you  have access to the previous disk data, or do you have to also recreate filesystems?

No access to the previous disk data on Alt-F or Linux. I've to reformat the partitions before I can mount the disks.

 

My older 1TB (ext2) and 2TB (ext3) drives are accessible on Alt-F as well as on Ubuntu using the SATA to USB drive connector.

But they don't use GPT, they do?
 
 They're both using MBR, and were both prepared using the old D-Link 1.05 firmware.


The following is data from the WD disk prepared using the Ubuntu command line:

Ubuntu14.04> sgdisk -p /dev/sdb

Disk /dev/sdb: 732566646 sectors, 2.7 TiB
Logical sector size: 4096 bytes

4KB  on a 3TB WD?

Disk identifier (GUID): 0DF8EA2F- ...
Partition table holds up to 128 entries
First usable sector is 6, last usable sector is 732566640
Partitions will be aligned on 64-sector boundaries
Total free space is 58 sectors (232.0 KiB)

Number     Start (sector)     End (sector)     Size     Code     Name
     1                64          2072639      7.9 GiB   8200
     2           2072640        732566640      2.7 TiB   8300


----------

Alt-F0.1RC4> sgdisk -p /dev/sda

But is this the same disk as above?

Yes. The output I pasted above are both from the WD drive, partitioned and formatted on Ubuntu 14.10 using sgdisk/mkfs. It is readable on Ubuntu 14.10 (64 bit) native and Lubuntu 12.10 (32 bit) VM running on OS X, but not on Alt-F.

Creating new GPT entries.
Disk /dev/sda: 5860533168 sectors, 2.7 TiB
Logical sector size: 512 bytes

512bytes
 


 
The following output is from the Toshiba drive, partitioned and formatted on Alt-F0.1RC4. It is readable only on Alt-F.

TOSHIBA prepared using Alt-F 0.1RC4

Alt-F0.1RC4> sgdisk -p /dev/sda
Disk /dev/sda: 5860533168 sectors, 2.7 TiB
Logical sector size: 512 bytes
Disk identifier (GUID): 1FCF1918-...

Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 5860533134
Partitions will be aligned on 64-sector boundaries
Total free space is 30 sectors (15.0 KiB)


Number  Start (sector)    End (sector)  Size       Code  Name
   1              64         1048639   512.0 MiB   8200 
   2         1048640      5860533134   2.7 TiB     8300



Ubuntu14.04> sgdisk -p /dev/sdb
Creating new GPT entries.

Disk /dev/sdb: 732566646 sectors, 2.7 TiB
Logical sector size: 4096 bytes
Disk identifier (GUID): 08649810-...

Partition table holds up to 128 entries
First usable sector is 6, last usable sector is 7325640
Partitions will be aligned on 256-sector boundaries
Total free space is 732566635 sectors (2.7 TiB)


Number  Start (sector)    End (sector)  Size       Code  Name


Notice that new GPT entries have to be created when the sgdisk command is used on the system it isn't created on. The sector size and boundaries are different. The GUID changes every time sgdisk -p is run on the system it isn't created on (due to new GPT entries being created?).

When the both disks (prepared either way) are read on Alt-F, the logical sector size is 512B. On Ubuntu, it is 4KB.

I think that there are two hypothesis: a sgdisk bug, or a kernel bug.
Alt-F is using sgdisk version 0.8.6

Ubuntu 14.04 is using sgdisk version 0.8.8.
 
When searching for the issue cause you have to always use the same disk, from the same manufacturer/model, as different manufacturers deal with bigger than 2TB disks in potentially different ways.
WD uses the "Advanced Format" way, where the drive "lies" to the operationg system saying that it has 512bytes physical sectors, while in reality it uses 4KB sectors. It then internaly translate 512bytes sector numbers to 4KB sectors. Other manufacturer might do it differently, so you can't do some tests on one disk and extrapolate the conclusions to another disk.

I've tested both drives in both scenarios. Both the WD and the Toshiba can be read by multiple systems except Alt-F when prepared in Linux, and both the drives can only be read on Alt-F when prepared in Alt-F.

 
So, what does /sys/block/sdX/queue/logical_block_size and /sys/block/sdX/queue/physical_block_size tells on your 64/32 bits linux distros? always using the same disk.

From your post I think they will report 4KB logical/512bytes physical for the WD disk (and what about the Toshiba disk?), while Alt-F will report 512bytes/512bytes. sgdisk might be using the value that the kernel reports, and that *might* be the reason why the partition it generates is not recognized by the other linux boxes and vice-versa.


WD prepared using Ubuntu14.04 (64 bit)

Ubuntu14.04 (64 bit)> 4096 Logical / 4096 Physical
Lubuntu12.10 (32 bit)> 4096 Logical / 4096 Physical
Alt-F0.1RC4> 512 Logical / 4096 Physical

Toshiba prepared using Alt-F
Ubuntu14.04 (64 bit)> 4096 Logical / 4096 Physical
Lubuntu12.10 (32 bit)> 4096 Logical / 4096 Physical
Alt-F0.1RC4> 512 Logical / 4096 Physical

You can also install and use 'parted' under Alt-F and see if it recognizes any of the two (Alt-F/other linux) disk partition tables.

Alt-F0.1RC4 parted 3.2> print all
Model: ATA TOSHIBA DT01ACA3 (scsi)
Disk /dev/sda: 3001GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:

Number  Start   End     Size    File system     Name  Flags
 1      32.8kB  8489MB  8489MB  linux-swap(v1)
 2      8489MB  3001GB  2992GB  ext4


Error: /dev/sdb: unrecognised disk label
Model: ATA WDC WD30EZRX-22D (scsi)                                       
Disk /dev/sdb: 3001GB
Sector size (logical/physical): 512B/512B
Partition Table: unknown
Disk Flags:


Again, WD is prepared on Ubuntu, Toshiba is prepared on Alt-F.
Oddly, parted 3.2 recognizes the logical and physical sector size on both drives as 512B instead of 512B Logical / 4096B Physical.
 
It is also important to report the different system software/kernel versions:

For Alt-F-0.1RC4 they are:

kernel 3.10.32 (uname -a)
sgdisk 0.8.6 (sgdisk --version)
parted 2.2 (parted --version)

Not so important:
fdisk BusyBox v1.20.2
sfdisk 3.07 (sfdisk -v)

Alt-F-0.1RC4
parted 3.2 (not 2.2)

Ubuntu 14.04 (64 bit)
kernel 3.13.0-32-generic
sgdisk 0.8.8
parted 2.3 (not 3.2)
fdisk util-linux 2.20.1
sfdisk util-linux 2.20.1
 
Needless to say this is a very important inter-interoperability issue for Alt-F, as most users expect to be able to use their disks existing data in case the box has a fatal hardware malfunction, so I would appreciate your feedback.

In case it's relevant, I have 2 x DNS-323 Rev B1 units (One was supposed to be a spare). I have tried the drives on both DNS-323 units in case it's a NAS hardware problem, but it made no difference.
 
Has anyone with 3/4TB disks this issue? Or has anyone with 3/4TB disks interchanged them between a linux box and Alt-F? either using SATA directly or through an USB adapter? All reports are needed.

Users who are reading this please note - If you're using a GPT ext4 formatted drive for Alt-F, you should try plugging them directly into your primary computer to check if you are still able to access your data.
In case your NAS box goes down, you still want to be able to access your data directly.

Thanks.


Thank you!
 


ADDENDUM: Comparing WD drive when prepared on Ubuntu vs Alt-F. Drive partitioned using sgdisk and formatted using mkfs.ext4 on both Ubuntu and Alt-F.

WD prepared using Ubuntu 14.04 (64 bit)
Ubuntu14.04> sgdisk -p /dev/sdb
Disk /dev/sdb: 732566646 sectors, 2.7 TiB
Logical sector size: 4096 bytes
Disk identifier (GUID): 0DF8EA2F- ...
Partition table holds up to 128 entries
First usable sector is 6, last usable sector is 732566640
Partitions will be aligned on 64-sector boundaries
Total free space is 58 sectors (232.0 KiB)

Number     Start (sector)     End (sector)     Size     Code     Name
     1                64          2072639      7.9 GiB   8200
     2           2072640        732566640      2.7 TiB   8300


Alt-F0.1RC4> sgdisk -p /dev/sda

Creating new GPT entries.
Disk /dev/sda: 5860533168 sectors, 2.7 TiB
Logical sector size: 512 bytes
Disk identifier (GUID): 5C9C3B84-...
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 5860533134
Partitions will be aligned on 2048-sector boundaries
Total free space is 5860533101 sectors (2.7 TiB)

Number  Start (sector)    End (sector)  Size       Code  Name


----------------------
WD prepared using Alt-F
Ubuntu14.04> sgdisk -p /dev/sdb
Disk /dev/sdb: 732566646 sectors, 2.7 TiB
Logical sector size: 4096 bytes
Disk identifier (GUID): 3026CE80- ...

Partition table holds up to 128 entries
First usable sector is 6, last usable sector is 732566640
Partitions will be aligned on 256-sector boundaries
Total free space is 732566635 sectors (2.7 TiB)


Number     Start (sector)     End (sector)     Size     Code     Name

Alt-F0.1RC4> sgdisk -p /dev/sdb
Disk /dev/sdb: 5860533168 sectors, 2.7 TiB

Logical sector size: 512 bytes
Disk identifier (GUID): 2EAE2E21-29DD-4EAD-8E6A-CCC0C48154A0

Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 5860533134
Partitions will be aligned on 64-sector boundaries
Total free space is 30 sectors (15.0 KiB)


Number  Start (sector)    End (sector)  Size       Code  Name
   1              64        16580671   7.9 GiB     8200 
   2        16580672      5860533134   2.7 TiB     8300 


>cat /sys/block/sdX/queue/logical_block_size ; cat /sys/block/sdX/queue/physical_block_size

WD prepared using Ubuntu14.04 (64 bit)
Ubuntu14.04 (64 bit)> 4096 Logical / 4096 Physical
Lubuntu12.10 (32 bit)> 4096 Logical / 4096 Physical
Alt-F0.1RC4> 512 Logical / 4096 Physical

WD prepared using Alt-F
Ubuntu14.04 (64 bit)> 4096 Logical / 4096 Physical
Lubuntu12.10 (32 bit)> 4096 Logical / 4096 Physical
Alt-F0.1RC4> 512 Logical / 4096 Physical


Alt-F parted 3.2> print all

WD prepared using Ubuntu14.04 (64 bit)
Error: /dev/sdb: unrecognised disk label
Model: ATA WDC WD30EZRX-22D (scsi)                                       
Disk /dev/sdb: 3001GB
Sector size (logical/physical): 512B/512B
Partition Table: unknown
Disk Flags:

WD prepared using Alt-F
Model: ATA WDC WD30EZRX-22D (scsi)
Disk /dev/sdb: 3001GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:

Number  Start   End     Size    File system     Name  Flags
 1      32.8kB  8489MB  8489MB  linux-swap(v1)
 2      8489MB  3001GB  2992GB  ext4

Ubuntu parted 2.3> print all
WD prepared using Ubuntu14.04 (64 bit)
Model: ASMT 2014 (scsi)
Disk /dev/sdb: 3001GB
Sector size (logical/physical): 4096B/4096B
Partition Table: gpt

Number  Start   End     Size    File system     Name  Flags
 1      262kB   8490MB  8489MB 
 2      8490MB  3001GB  2992GB 

WD prepared using Alt-F
Error: /dev/sdb: unrecognised disk label

Note that Alt-F parted 3.2 reads the logical and physical sector size as 512B whether prepared on Ubuntu or Alt-F, while Ubuntu parted 2.3 reports a drive prepared on Ubuntu it as 4096B, matching the information in /sys/block.

João Cardoso

unread,
Aug 11, 2014, 10:40:10 AM8/11/14
to

That's a lot of information to digest, thanks for being so exhaustive.

Some notes after a first glimpse at it:

I have updated parted and gptdisk to their last versions after your first post, can you also please also try gptfdisk/sgdisk?
I haven't updated sgdisk because that would be a mess (it would be installed on disk, what would make impossible to partition the disk where it is run from), but I attach it here, please use it also from /tmp, or /root, don't copy it to /usr/sbin).

I probably have to contact gptfdisk author, to see if the issue is version related or what, and contacting him requires using his software last version.

BTW, have you played with your WD JUMPER? Hope not, that is not recommended.
Is there any possibility to override the SATA/USB adapter, connecting the drive directly to the computer motherboard?

What troubles me is why Ubunto reports 4KB physical sectors, when it is know that WD "advanced format" reports 512bytes! Read http://www.ibm.com/developerworks/library/l-4kb-sector-disks/ and/or http://www.rodsbooks.com/gdisk/advice.html

Thanks (and Looking forward)

PS: I thing that this issue only applies to 3/4TB disks, as I have done interoperability tests on GPT on smaller disks.

sgdisk.gz

FeebleOldMan

unread,
Aug 12, 2014, 1:39:31 AM8/12/14
to


On Monday, 11 August 2014 22:40:10 UTC+8, João Cardoso wrote:

That's a lot of information to digest, thanks for being so exhaustive.

I'm very thankful for your help.

 
Some notes after a first glimpse at it:

I have updated parted and gptdisk to their last versions after your first post, can you also please also try gptfdisk/sgdisk?

Ok I've installed gptfdisk 0.8.10 via the Alt-F web interface.

Alt-F gdisk 0.8.10 (GPT fdisk)
WD prepared using Ubuntu14.04 (64bit)
Disk /dev/sdb: 5860533168 sectors, 2.7 TiB
Logical sector size: 512 bytes
Disk identifier (GUID): 61812E4F-C0EC-4C7D-AE9A-414238F808B9

Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 5860533134
Partitions will be aligned on 2048-sector boundaries
Total free space is 5860533101 sectors (2.7 TiB)

Number  Start (sector)    End (sector)  Size       Code  Name

No apparent difference with the output from Alt-F sgdisk 0.8.6.
 
I haven't updated sgdisk because that would be a mess (it would be installed on disk, what would make impossible to partition the disk where it is run from), but I attach it here, please use it also from /tmp, or /root, don't copy it to /usr/sbin).

Alt-F sgdisk 0.8.10
WD prepared using Ubuntu14.04 (64bit)
Creating new GPT entries.
Disk /dev/sdb: 5860533168 sectors, 2.7 TiB

Logical sector size: 512 bytes
Disk identifier (GUID): 743B926F-8538-4B78-99E7-A976E04F2417

Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 5860533134
Partitions will be aligned on 2048-sector boundaries
Total free space is 5860533101 sectors (2.7 TiB)

Number  Start (sector)    End (sector)  Size       Code  Name


No apparent difference vs 0.8.6

Do you want me to prep the drive using sgdisk 0.8.10 on Alt-F?

I probably have to contact gptfdisk author, to see if the issue is version related or what, and contacting him requires using his software last version.

BTW, have you played with your WD JUMPER? Hope not, that is not recommended.

No, I never touched the jumpers on WD or the Toshiba.
 
Is there any possibility to override the SATA/USB adapter, connecting the drive directly to the computer motherboard?

I'll have to get back to you on this. I currently have no access to desktop computers - only laptops. Without anyone else trying to connect their Alt-F drive directly to a motherboard there is a possibility that it might be the SATA/USB adapter that is causing the problem.

What troubles me is why Ubunto reports 4KB physical sectors, when it is know that WD "advanced format" reports 512bytes! Read http://www.ibm.com/developerworks/library/l-4kb-sector-disks/ and/or http://www.rodsbooks.com/gdisk/advice.html

Thanks (and Looking forward)
 
Once again, I'm very grateful for your help.
 
PS: I thing that this issue only applies to 3/4TB disks, as I have done interoperability tests on GPT on smaller disks.





EDIT: I figured I could try plugging in the SATA/USB drive adapter to the NAS. Turns out that as long as the drive is plugged through the USB adapter, the logical sector size becomes 4096B, and becomes unreadable if it was prepared with a logical sector size of 512B. i.e. I can read the drive prepared on Ubuntu via the USB adapter on the NAS as long as I connect it to the NAS through the USB adapter.

More info here: http://ask.metafilter.com/235067/Why-would-a-SATA-drive-work-in-a-SATAUSB-dock-but-not-via-SATA-cable

if you take a drive that was partitioned for 4K logical sectoring (which is the only way to define a 3TB partition using an MBR partition table) and hook it up in such a way as to make Windows treat it as having 512-byte logical sectoring, all the partitions will appear to be 1/8 their intended size. Not only that but they will start at the wrong disk offsets and Windows will not find the filesystems inside them.

Also

When queried via SATA, the ST3000DM001 reports itself as having 512-byte logical and 4096-byte physical sectors. Early versions of the Intel drivers for the ICH7 SATA controller on your motherboard are naive enough to pass this information on to Windows as-is, and Windows reacts to knowing the 4K physical sector size by screwing things up. Later driver versions just lie about it and tell Windows that the drive has purely traditional 512-byte sectoring, and everything then Just Works. Windows 8 and Windows Server 2012 don't screw things up any more, so drivers for those don't need to tell them white lies.

I expect the reason your drive works properly in a USB dock is that the standard Windows USB mass storage driver doesn't care about physical sector sizes and doesn't report them to Windows; it works purely in logical sectors. There are some special-purpose USB adaptors, notably those supplied with the large Western Digital USB drives, that do actually report a 4K logical sector size to work around partition table and 32-bit Windows limitations but I would be surprised to find that a slot-in SATA to USB docking station is doing this.


The large drives are trying to run in compatibility mode (512e) in Alt-F, causing the sectors to be misaligned. Could this be fixed by updating the Alt-F kernel or is the motherboard on the DNS-323 Rev B1 too old?

EDIT 2: I tried preparing the WD through the USB adapter connected to the NAS to check if it might then work on both the NAS and the USB adapter. It does not work. I also tried using the default alignment values in sgdisk (by leaving out the -a option) to see if it might cause the sectors to align properly. The default was 2048 when the drive was plugged into the NAS, and 256 when the drive was plugged into the USB adapter which was plugged into the NAS. Needless to say, it still didn't work.

João Cardoso

unread,
Aug 12, 2014, 6:24:43 PM8/12/14
to

[Top posting to try to get a summary]

The issue seems to be the SATA/USB adapter.

As the drive is greater than 2TB the USB adapter "lies" and reports a logical sector size of 4KB instead of what the drive reports, 512Bytes. (Internally, the drive uses a physical 4KB sector, but that doesn't matter.)

That's why you see 4096/4096 logical/physical when you attach the disk through the USB adapter and 512/4096 when you attach is through the box SATA slots. You have still to confirm this you when you are able to attach it to a desktop computer SATA connector. Will e-Sata also lie?

For MBR this is "OK", as MBR fits in the disk first 512 bytes (the disk first 512 bytes sector). But for GPT that will not work, as GPT maintains a MBR compatible partition table at sector 0 and reads or writes its own partition table at sector 1 (and a backup at the disk last sector).

So, when creating a GPT partition table when 512 is the logical sector size, the GPT is created starting at the disk byte 512 (its sector 1). When reading the GPT when 4KB logical sectors are reported, the GPT is searched also on sector 1, but what is returned from the disk is the disk data starting at byte 4096 (now the disk sector 1). Because the software asks "give me the data on sector 1". And nothing was written there.
The reverse also fails: writing the GPT at the disk starting at the 4096 byes, and then trying to read it at the disk byte 512.

Thus, it is not possible to use the disk interchangeably through the SATA and a lying USB adapter. It's not the kernel fault (it's recent enough), nor the box USB, it's the SATA/USB adapter fault.
You missed to (directly) report what /sys/block/xxx says when the disk is attached to the box through USB, but it should be 4096/4096.

The only think that should work is to always use the disk using the USB adapter, be it at the laptop or at the box.
I'm afraid that Alt-F webUI has 512bytes hardwired in its code  as the logical sector size (shame!), so preparing the USB attached disk under Alt-F using its webUI probably will not make it readable under Ubunto, or vice-versa.
Not sure. But with drives with 4KB native logical sectors the webUI will probably fail -- this kind of drives are starting to appear in the professional market.

Does your experience confirms the above?

PS: see Rod Smith ( gptfdisk author) reply to this post

Note-this issue has nothing to do with partition alignment.
Reply all
Reply to author
Forward
0 new messages