21

Is useful to use -T largefile flag at creating a file-system for a partition with big files like video, and audio in flac format?

I tested the same partition with that flag and without it, and using tune2fs -l [partition], I checked in "Filesystem features" that both have "large_file" enabled. So, is not necessary to use -T flag largefile?

Improve this question
1
  • 1
    Note that I was confused between large_file (got in tune2fs) and largefile; it looks that they're arguments for different things.
    – Marc
    Commented Jul 16, 2012 at 9:17

2 Answers 2

Reset to default
36

The -T largefile flag adjusts the amount of inodes that are allocated at the creation of the file system. Once allocated, their number cannot be adjusted (at least for ext2/3, not fully sure about ext4). The default is one inode for every 16K of disk space. -T largefile makes it one inode for every megabyte.

Each file requires one inode. If you don't have any inodes left, you cannot create new files. But these statically allocated inodes take space, too. You can expect to save around 1,5 gigabytes for every 100 GB of disk by setting -T largefile, as opposed to the default. -T largefile4 (one inode per 4 MB) does not have such a dramatic effect.

If you are certain that the average size of the files stored on the device will be above 1 megabyte, then by all means, set -T largefile. I'm happily using it on my storage partitions, and think that it is not too radical of a setting.

However, if you unpack a very large source tarball of many files (think hundreds of thousands) to that partition, you have a chance of running out of inodes for that partition. There is little you can do in that situation, apart from choosing another partition to untar to.

You can check how many inodes you have available on a live filesystem with the dumpe2fs command:

# dumpe2fs /dev/hda5
[...]
Inode count:              98784
Block count:              1574362
Reserved block count:     78718
Free blocks:              395001
Free inodes:              34750

Here, I can still create 34 thousand files.

Here's what I got after doing mkfs.ext3 -T largefile -m 0 on a 100-GB partition:

Filesystem           1M-blocks      Used Available Use% Mounted on
/dev/loop1              102369       188    102181   1% /mnt/largefile
/dev/loop2              100794       188    100606   1% /mnt/normal

The largefile version has 102 400 inodes while the normal one created 6 553 600 inodes, and saved 1,5 GB in the process.

If you have a good clue on what size files you are going to put on the file system, you can fine-tune the amount of inodes directly with the -i switch. It sets the bytes per inode ratio. You would gain 75% of the space savings if you used -i 65536 while still being able to create over a million files. I generally calculate to keep at least 100 000 inodes spare.

Improve this answer
2
  • 1
    nice answer, but where you said, "and saved 1,5 GB in the process." you should be saying "but used 1,5 GB space for the extra inodes". You make it sound like normal mode created more inodes and also left more free space on the disk.
    – localhost
    Commented Aug 30, 2017 at 4:34
  • "I generally calculate to keep at least 100 000 inodes spare." - why? Surely 0 spare (and 0 more needed) is optimal? Are you really worried you might be off by 100K on how many files or directories you'll have?
    – OJFord
    Commented Feb 3, 2018 at 17:05
8

I think you are mixing up two completely different and independent concepts.

The large_file feature that you can see in the output of dumpe2fs means that this filesystem can hold files larger than 2 GiB, I think it is set automatically by modern kernels. It has nothing to do with the -T option of mke2fs.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .