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/sdasgdisk --set-alignment=8 --new=1:64:+8096M --typecode=1:8200 /dev/sdasgdisk --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
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.
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?
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?
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
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.
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.
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.