3TB EXT4 Partition

[nry]

Im quite new to creating partitions etc within linux (Ubunut 10.04 LTS x64) so thats probably one of the reasons im ending in a bit of a mess here.

I have just got 2x 3TB Hitachi drives, I have created a partition on them using the following...

1) fdisk /dev/sdi
2) Created a primary partition (1)
3) formatted the partition to ext4 using
mkfs -t ext4 /dev/sdi1
4) reduced the reserved space
tunefs -m 0 /dev/sdi1

This is the output from fdisk
Disk /dev/sdi: 3000.6 GB, 3000592982016 bytes
255 heads, 63 sectors/track, 364801 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x66ebeb3c

Device Boot Start End Blocks Id System
/dev/sdi1 1 267349 2147480811 83 Linux

In webmin it says the following for this drive (in various places:
Size 1.97 TB / Free 1.97 TB
0% Used

Then using the samba shares, I have it down as 2.16TB free with nothing written on the drive.

From my understanding I should have around 2.72TB

Why is this happening?

 

[ziggo0]

You need to use gdisk (if you prefer fdisk), parted or gparted to make your drive GPT formatted and not MBR, since MBR doesn't support over 2tb. I have a few 2.5TB disks in my file server running Ubuntu Server 10.04.3 so you should be just fine, apt-get can install all 3 of those.

 

[nry]

Ah makes sense.

So I used gpart to delete the partitions and switch to GPT and now have the following...
Command (? for help): p
Disk /dev/sdi: 5860533168 sectors, 2.7 TiB
Disk identifier (GUID): 20EC6804-635A-0CB8-4B65-FFE01C430703
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 5860533134
Total free space is 0 sectors (0 bytes)

Number Start (sector) End (sector) Size Code Name
1 34 5860533134 2.7 TiB 0700 Linux/Windows data

Did the same command above (after a restart)
mkfs -t ext4 /dev/sdi1

But in webmin I still have the following after remounting
Size 1.97 TB / Free 1.87 TB

(it has 5% reserved here)

 

[ziggo0]

That's strange....says your partition is 2.7gb but it isn't formatting. I use:

mkfs.ext4 -m 0 /dev/sdi1

Should be the same thing...worked for me when I was messing with the 2.5TB drive.

 

[nry]

Just ran your command on it...

root@nas:~# mkfs.ext4 -m 0 /dev/sdi1
mke2fs 1.41.11 (14-Mar-2010)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
134217728 inodes, 536870202 blocks
0 blocks (0.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=4294967296
16384 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968,
102400000, 214990848, 512000000

Writing inode tables: done
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done

This filesystem will be automatically checked every 20 mounts or
180 days, whichever comes first. Use tune2fs -c or -i to override.
root@nas:~#

Still get this though...
Size 1.97 TB / Free 1.97 TB

 

[drescherjm]

Did you try using df too see how much free space you have on the drive?

 

[nry]

Size 2.69 TB / Free 2.69 TB

Thanks all

 

[houkouonchi]

Also a heads up the root reserve can be changed on the fly (even when the fs is mounted) with tune2fs:

tune2fs -m0 /dev/sdXX

I also like to prevent automatic fsck's as well as its default I think is every 20 mounts or 52 weeks (1 year):

tune2fs -c 0 -i 0 /dev/sdXX

This makes the mount count (-c) zero and interval (-i) to nothing which means no automatic fsck's. This is not as big of a problem with ext4 but an fsck on a 3TB or more volume on ext3 can take several hours and sucks when it happens unexpectedly on a random reboot.

 

[jwcalla]

Also a heads up the root reserve can be changed on the fly (even when the fs is mounted) with tune2fs:

What is a respectable reserve for a storage drive that has no OS installed? Would the reserve ever come into play or is that only used for OS drives?

 

[drescherjm]

I use 0 or 1 percent for that.

 

[houkouonchi]

What is a respectable reserve for a storage drive that has no OS installed? Would the reserve ever come into play or is that only used for OS drives?

All that is, is a reserved percentage of space for the superuser (root). It effects how df reads and honestly I dont see a reason (almost ever) to use it. I guess the only good effect it could have is if say an OS partition logs will continue loging (as syslog is usually running as root) even when other stuff breaks.

I haven't used extX partitions on my own machines for many years now but even when I did I always used a 0% root reserve. Also when I used ext3 (probably relevent with ext4 as well as it does not dynamically create inodes AFAIK) I would manually specify the number of inodes with -N when doing a mkfs. Most systems (even large arrays) will never need more than 5-20 million inodes unless your dealing with mail or a bunch of small files. Inodes can use a significant amount of space and back when I did use ext3 and I would manually specify around 700k inodes for each drive (drives 250-500GB). On a 3TB drive I myself would not allow for more than 10 million inodes.

On just a 3 or 4 TB partition you can eaily have 200-500 million inodes which is way overkill. When you have that many inodes its easily eating up 10s of gigabytes of space (if not >100GB).

You can check how many inodes your using now with:

df -hi

On my main used array which is 36 TB usable and 26 TB used (opposed to my largest which is 84TB total and 5.6 TB used) I am only using 8 million inodes for that 26 TB of space.

 

[unhappy_mage]

All that is, is a reserved percentage of space for the superuser (root). It effects how df reads and honestly I dont see a reason (almost ever) to use it. I guess the only good effect it could have is if say an OS partition logs will continue loging (as syslog is usually running as root) even when other stuff breaks.

Depending on how your system is set up, letting the disk fill up entirely can prevent logins, requiring a reboot into single-user mode or other drastic measures. This is widely regarded as a problem