# Seagate ST3000DM001 ext4 formatting

## dilbot

If I format a Seagate ST3000DM001 with ext4, it gives 2145430320 K blocks.    I'm used to a few % for overhead, but this looks like it's more like 30%.    Normally on a 2TB Seagate I get 1949547144 K blocks.    There's not much of a benefit in going to 3Tb disks at this rate.   Anyone know the reason why this is?

----------

## aCOSwt

 *dilbot wrote:*   

> it gives 2145430320 K blocks.

 

Where do you read that from ?

If you use the dumpe2fs utility, you should be able to understand where your 30% have gone.

As well as what you can do to reduce this amount... a little.   :Twisted Evil: 

If you still get problems, post the output of 

```
dumpe2fs -h /dev/_your_sd_device
```

As well as your emerge --info

BTW : You did build your filesystem with auto_64-bit_support

Just asking this because your number of blocks is strangely close to the max of a signed 32 bits int.

----------

## py-ro

Please show your partioning.

----------

## s4e8

You need EFI GUID partition, the traditional fdisk partition limited to 2T.

----------

## dilbot

Maybe it is a 64-bit flag I'm missing somewhere, but I don't see any auto_64 switches in the ext4 filesystem or elsewhere in the kernel config tree.   Here's the uname, dumpe2fs, df, and fdisk outputs.

j173 linux # uname -a

Linux j173 3.2.12-gentoo #2 SMP Thu Jun 28 18:47:52 PDT 2012 i686 Intel(R) Core(TM)2 Quad CPU Q8300 @ 2.50GHz GenuineIntel GNU/Linux

j173 linux # dumpe2fs -h /dev/sdd1

dumpe2fs 1.42 (29-Nov-2011)

Filesystem volume name:   <none>

Last mounted on:          /sdd1

Filesystem UUID:          d9a3696e-47d1-4048-a764-067d4333380f

Filesystem magic number:  0xEF53

Filesystem revision #:    1 (dynamic)

Filesystem features:      has_journal ext_attr resize_inode dir_index filetype needs_recovery extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize

Filesystem flags:         signed_directory_hash 

Default mount options:    user_xattr acl

Filesystem state:         clean

Errors behavior:          Continue

Filesystem OS type:       Linux

Inode count:              134217728

Block count:              536870655

Reserved block count:     26843532

Free blocks:              528396005

Free inodes:              134217717

First block:              0

Block size:               4096

Fragment size:            4096

Reserved GDT blocks:      896

Blocks per group:         32768

Fragments per group:      32768

Inodes per group:         8192

Inode blocks per group:   512

Flex block group size:    16

Filesystem created:       Fri Nov 30 04:20:05 2012

Last mount time:          Fri Nov 30 04:20:28 2012

Last write time:          Fri Nov 30 04:20:28 2012

Mount count:              1

Maximum mount count:      -1

Last checked:             Fri Nov 30 04:20:05 2012

Check interval:           0 (<none>)

Lifetime writes:          136 MB

Reserved blocks uid:      0 (user root)

Reserved blocks gid:      0 (group root)

First inode:              11

Inode size:               256

Required extra isize:     28

Desired extra isize:      28

Journal inode:            8

Default directory hash:   half_md4

Directory Hash Seed:      e3d2183e-4e4e-426e-991d-b677359bec8f

Journal backup:           inode blocks

Journal features:         journal_incompat_revoke

Journal size:             128M

Journal length:           32768

Journal sequence:         0x00007ea3

Journal start:            25977

j173 linux # df -k

Filesystem      1K-blocks       Used  Available Use% Mounted on

/dev/sdd1      2145430320 1892946340  145109852  93% /sdd1

j173 linux # fdisk /dev/sdd

Disk /dev/sdd: 3000.6 GB, 3000592982016 bytes

90 heads, 3 sectors/track, 21705678 cylinders, total 5860533168 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: 0x76d4ba03

   Device Boot      Start         End      Blocks   Id  System

/dev/sdd1            2048  4294967294  2147482623+  83  Linux

----------

## dilbot

looked at EFI_PARTITION - here's what I have:

 Symbol: EFI_PARTITION [=y]  

  | Type  : boolean

  | Prompt: EFI GUID Partition support

  |   Defined at block/partitions/Kconfig:236

  |   Depends on: BLOCK [=y] && PARTITION_ADVANCED [=y]

  |   Location:

  |     -> Enable the block layer (BLOCK [=y]) 

  |       -> Partition Types     

  |         -> Advanced partition selection (PARTITION_ADVANCED [=y])

  |   Selects: CRC32 [=y]         

--- Enable the block layer 

  [*]   Support for large (2TB+) block devices and files  

  [*]   Block layer SG support v4  

  [ ]   Block layer SG support v4 helper lib    

  [ ]   Block layer data integrity support   

  Partition Types  --->      

  IO Schedulers  --->

----------

## py-ro

You got mbr partition Layout, it can't contain Partitions larger then 2TB.

You can do 2 things.

Do 2 Partitions, one a bit over 1TB and the second with the remaining space.

or

Switch to GPT layout.

Bye

Py

----------

## aCOSwt

Well, so you used fdisk to create the partition ? Correct ?

fdisk cannot create partitions > 2TB (You must have seen a warning displayed when you created it)

Use parted instead.

----------

## dilbot

@ aCOSwt 

You're right, there is a warning:

" WARNING: The size of this disk is 3.0 TB (3000592982016 bytes).

DOS partition table format can not be used on drives for volumes

larger than (2199023255040 bytes) for 512-byte sectors. Use parted(1) and GUID 

partition table format (GPT)."

But when it started with DOS partition table, I didn't pay any attention to it  :Wink: 

Thanks everyone, I'll switch over to GPT.     After so many years using fdisk it'll be a bit of a change for me.

----------

## wcg

You may find these documents helpful in switching over:

http://www.rodsbooks.com/gdisk/

http://rodsbooks.com/gdisk/bios.html

http://www.rodsbooks.com/efi-bootloaders/index.html

http://www.rodsbooks.com/bios2uefi/

----------

