# ext4 : How to make up the filesystem room?

I've lately formatted a 1.5 TB drive with the purpose of changing ntfs with ext4.

After that I saw that the documents I conserved do not fit on the new dividing.

df:

ext4 (ext3 & ext2 show the same behavior)
Filesystem      1K-blocks   Used  Available Use% Mounted on
/dev/sdb1      1442146364   71160 1442075204    1% /media/Seagate

ntfs (similar to all other options that gparted offers):
/dev/sdb1      1465137148  110700 1465026448    1% /media/Seagate


That 1K - obstructs distinction suggests a glaring 22 GiB much less useful room.

I have actually currently implemented

tune2fs -O \^has_journal
tune2fs -r 0
tune2fs -m 0


with, unsurprisingly, no result as that does not influence blocks that simply aren't there.

Still, fdisk records that the ext4 dividing covers the whole disk.

fdisk -l /dev/sdb:

WARNING: GPT (GUID Partition Table) detected on '/dev/sdb'! The util fdisk doesn't support GPT. Use GNU Parted.

Disk /dev/sdb: 1500.3 GB, 1500301910016 bytes
255 heads, 63 sectors/track, 182401 cylinders, total 2930277168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000
Device Boot      Start         End      Blocks   Id  System
/dev/sdb1               1  2930277167  1465138583+  ee  GPT


And hence e. g. resize2fs records that there is "Nothing to do!"

dumpe2fs -h /dev/sdb1:
dumpe2fs 1.41.14 (22-Dec-2010)
Filesystem volume name:   <none>
Last mounted on:          <not available>
Filesystem UUID:          d6fc8971-89bd-4c03-a7cd-abdb945d2173
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      ext_attr resize_inode dir_index filetype extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags:         signed_directory_hash
Default mount options:    (none)
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              91578368
Block count:              366284288
Reserved block count:     0
Free blocks:              360518801
Free inodes:              91578357
First block:              0
Block size:               4096
Fragment size:            4096
Reserved GDT blocks:      936
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         8192
Inode blocks per group:   512
Flex block group size:    16
Filesystem created:       Sat May 21 17:12:04 2011
Last mount time:          Sat May 21 17:15:30 2011
Last write time:          Sat May 21 17:24:32 2011
Mount count:              1
Maximum mount count:      32
Last checked:             Sat May 21 17:12:04 2011
Check interval:           15552000 (6 months)
Next check after:         Thu Nov 17 16:12:04 2011
Lifetime writes:          1372 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
Default directory hash:   half_md4
Directory Hash Seed:      c334e6ef-b060-45d2-b65d-4ac94167cb09
Journal backup:           inode blocks


What is making use of that missing out on room?

0
2019-12-02 03:14:00
Source Share

Let is see. The tool dimension is 1,465,138,583 1/2 kB = 1,500,301,909,504 B. The filesystem contains 366,284,288 blocks of 4096 B each, which is 1,500,300,443,648 B. I do not recognize what the continuing to be 1,465,856 B (1.4 MEGABYTES) are made use of for (added duplicates of the superblock? I recognize there are a couple of kB of room at the start for the bootloader.).

The filesystem has 91,578,368 inodes of 256 bytes each, which occupies 23,444,062,208 B (concerning 22 GB, tip, tip). After that there is 1,442,146,364 kB = 1,476,757,876,736 B for documents materials. This makes up 23,444,062,208 B+1,476,757,876,736 B = 1,500,201,938,944 B. The continuing to be dimension is 98,504,704 B = 24,029 blocks which remains in the appropriate array to be the journal dimension.

As you can see, every little thing is made up. (Ok, virtually every little thing, yet we are chatting megabytes, not gigabytes.)

0
2019-12-03 05:30:29
Source

First of all, the distinction in readily available room you are seeing does not suggest in all that there is room "wasted" ; it is not thrown away due to the fact that it is of basic relevance for the filesystem to function. You need to not contrast Ext4 and also NTFS this way without a large "but" defining all the layout and also architectural distinctions in between filesystems, as well as additionally specifics of each execution (as an example just how each vehicle driver records vacuum to the VFS layer).

Visualize the partition as a massive room where you can place any kind of items of information you have. If you have just one item of information with a dimension equivalent to the partition, you can simply write it beginning at the start of the partition and also be trendy with it. Yet you do not. Rather you might have hundreds of tiny documents, and also all these documents organized in various means, and also each documents related to several various other tiny items of information (name, date/time and also approvals), etc You need to arrange the large room of the partition to make sure that you can get to all these items of information promptly and also successfully. Additionally, you need to be worried about just how to write new items of information and also throw out old items of information successfully. You require data structures.

And also there is a lot of data structures. Several of them are really foolish, others permit you to fetch information quicker at the expenditure of even more slower creates, various other permit creates quicker at the expenditure of reviews, some still might be great at both reviews and also creates yet call for lengthy stops and also still expenses while it repositions the information, etc

You absolutely desire a system that :

1. Is really rapid to write details on it ;
2. Is really rapid to fetch details from it ;
3. Is efficient arranging and also taking care of the details saved in it ;
4. Makes excellent usage of the room (partition) where the filesystem is saved ;
5. Is resistant versus hardware troubles, to make sure that you still get most or all your details back on partial system failings ;
6. Is resistant versus software program troubles, to make sure that a bug in an application, or a destructive application mounted, will certainly not destroy your information completely ;
7. Is resistant versus human mistakes, to make sure that it forgives you when you mistakenly gets the system to delete something you should not (a.k.a. the trash/recycle container).

High - efficiency filesystems permit really quickly reviews and also creates at the expenditure of some room. Several of the fastest information frameworks made use of in filesystems, like hash tables and also B-trees, are really intricate, and also they book even more room than it is in fact in operation in order to permit really rapid accessibilities.

Ext4 has various other vital buildings. There is no solitary factor - of - failing in the filesystem. There are several duplicates of essential information spread out via the partition, while a few other filesystems (I can not claim for NTFS) might provide all your information unreadable if a failing takes place on the appropriate place. Additionally, Ext4 gets a great deal of room for your information right at filesystem production phase, while NTFS expands with your information.

0
2019-12-03 05:30:16
Source