Large disk support

[reg]

I have been using tinycore on a Wyse thin term as a NAS device for a while now.  I decided it would be nice to consolidate a bunch of smaller (largest is 1TB) disks into one new big disk.  I went off and procured a 6TB drive.  When I run fdisk on it from the 32 bit flavor of tinycore, it shows up as 1.4tb:

Disk /dev/sdb: 1493 GB, 1603128614912 bytes, 3131110576 sectors
194902 cylinders, 255 heads, 63 sectors/track
Units: cylinders of 16065 * 512 = 8225280 bytes

Device  Boot StartCHS    EndCHS        StartLBA     EndLBA    Sectors  Size Id Type
/dev/sdb1    0,1,1       1023,254,63         63 3131100629 3131100567 1493G 83 Linux

And as expected, if I make an ext4 fs on it, the filesystem is 1.4TB:

root@san:/# df -h /mnt/sdb1/
Filesystem                Size      Used Available Use% Mounted on
/dev/sdb1                 1.4T     76.0M      1.4T   0% /mnt/sdb1

I had read that ext4 can support up to 1 exbibyte, but apparently other pieces need to be in place as well.  Is it possible in tinycore to have one partition that is larger than 1.4TB?

[Rich]

Hi reg
According to:
https://gparted.org/display-doc.php?name=help-manual#gparted-specify-partition-type
MSDOS partitions are limited to 2TB. So breaking it into 3 partitions might be one option. The other possibility might be using
GUID partition tables (GPT). I've never dealt with GPT so you might have to do some Googling to see if it's feasible with your
hardware. Either way I'd recommend using a tool like  gparted  to handle the details.

[reg]

I think the root problem is fdisk is not allowing me to make a larger partition.  This is funny, I have not had a disk size problem is like a decade.

I am not concerned about what msdos can or can not support, this is going to be formatted ext4, but I will have a look at gpartd and see if that sees the entire disk.  I am at a bit of loss as to why fdisk only sees it as a 1.4TB drive unless something is overflowing inside fdisk.

[reg]

I have done a bunch of reading.  The best reference I can find is here:

https://www.ibm.com/developerworks/library/l-gpt/index.html

The author of this is behind gdisk.  I have found gdisk for tinycore.  However, I am still only seeing part of the drive in gdisk:

root@box:/opt# gdisk /dev/sdb
GPT fdisk (gdisk) version 0.8.7

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.

Command (? for help): p
Disk /dev/sdb: 3131110576 sectors, 1.5 TiB
Logical sector size: 512 bytes
Disk identifier (GUID): B0D2A86A-4A97-4ABE-AD8F-6A33BF429E04
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 3131110542
Partitions will be aligned on 2048-sector boundaries
Total free space is 2014 sectors (1007.0 KiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048      3131110542   1.5 TiB     8300  Linux filesystem

Command (? for help):

And this is a 6 TiB disk.  I can not been able to find CHS info on it yet.  This is amazingly frustrating only because I thought the longest phase of this was going to be copying everything, not getting the disk set up!

Does anybody know if EFI GUID Partition Support in the Partition Types area of the Enable the Block Layer configuration area if the kernel options is turned on in tinycore (32 bit)?

[reg]

Many thanks to Mr. Rod Smith, he wrote a very definitive blurb on gdisk (http://www.rodsbooks.com/gdisk/)  After going over my setup a few times and being pretty sure I was not doing anything wrong, I dropped Mr. Smith a note.  The problem is in the USB to SATA adapter that I was using, and this is a common failure in most of the USB to SATA adapters out there.  He hit the nail right on the head.  So fair warning:  If you want to use a big disk, it is probably not going to work with a USB to SATA bridge.  Sadly that rules out hanging large disks off of a lot of small, low powered devices.  I was using a thin term for example, trying to keep the total power draw to below 25W.  Back to the drawing board.

Again, a very special thank you to Mr. Rob Smith of http://www.rodsbooks.com

[curaga]

The old, IDE-only thin clients may not be suitable, but some of the newer ones have SATA ports. You can also use a new-ish low-power platform like AMD AM1 (25W TDP, if you configure it with the powersave governor it'd use less), or one of the ARM boards. edit: Intel also had some low-power boards before Atoms like D201GLY2 that should be available quite cheap now.

[Rich]

... MSDOS partitions are limited to 2TB. So breaking it into 3 partitions might be one option. ...

I think the root problem is fdisk is not allowing me to make a larger partition.  This is funny, I have not had a disk size problem is like a decade.

I am not concerned about what msdos can or can not support, this is going to be formatted ext4, but I will have a look at gpartd and see if that sees the entire disk.  I am at a bit of loss as to why fdisk only sees it as a 1.4TB drive unless something is overflowing inside fdisk.

The reference was to the MSDOS partitioning scheme not to the type of formatting used on an individual partition. More than
likely all those smaller disks on your NAS use MSDOS style partitioning with EXT type formatting.

[reg]

Rich: Yes, I understand your statement now after some reading.  It had never occured to be before that the fdisk in Linux was creating MSDOS type partitions.  This is to some extent the kind of thing that gives Linux a bad name.  Advertising that ext4 can create huge file systems, which is true, but not in an "out of the box" setup.  It seems the old fdisk should have been swapped out for gdisk a long time ago. 

curaga:  It is not so much the clients as it is a function of the USB to SATA bridge.  The one I was using was old.  Further clarification from Rod revealed that there are USB to SATA bridges that can deal with large disks.  You just need to look for them.  If it does not state it will support big disks, it probably does not.

So, I am now looking at USB to SATA bridges that will support large disks.

[core-user]

Maybe try a USB3, with backward compatibility(?).