Frank Steinmetzger wrote: > <<<SNIP>>> > > When formatting file systems, I usually lower the number of inodes from the > default value to gain storage space. The default is one inode per 16 kB of > FS size, which gives you 60 million inodes per TB. In practice, even one > million per TB would be overkill in a use case like Dale’s media storage.¹ > Removing 59 million inodes × 256 bytes ≈ 15 GB of net space for each TB, not > counting extra control metadata and ext4 redundancies. > > The defaults are set in /etc/mke2fs.conf. It also contains some alternative > values of bytes-per-inode for certain usage types. The type largefile > allocates one inode per 1 MB, giving you 1 million inodes per TB of space. > Since ext4 is much more efficient with inodes than ext3, it is even content > with 4 MB per inode (type largefile4), giving you 250 k inodes per TB. > > For root partitions, I tend to allocate 1 million inodes, maybe some more > for a full Gentoo-based desktop due to the portage tree’s sheer number of > small files. My Surface Go’s root (Arch linux, KDE and some texlive) uses > 500 k right now. > > > ¹ Assuming one inode equals one directory or unfragmented file on ext4. > I’m not sure what the allocation size limit for one inode is, but it is > *very* large. Ext3 had a rather low limit, which is why it was so slow with > big files. But that was one of the big improvements in ext4’s extended > inodes, at the cost of double inode size to house the required metadata. >
This is interesting. I have been buying 16TB drives recently. After all, with this fiber connection and me using torrents, I can fill up a drive pretty fast, but I am slowing down as I'm no longer needing to find more stuff to download. Even 10GB per TB can add up. For a 16TB drive, that's 160GBs at least. That's quite a few videos. I didn't realize it added up that fast. Percentage wise it isn't a lot but given the size of the drives, it does add up quick. If I ever rearrange my drives again and can change the file system, I may reduce the inodes at least on the ones I only have large files on. Still tho, given I use LVM and all, maybe that isn't a great idea. As I add drives with LVM, I assume it increases the inodes as well. If so, then reducing inodes should be OK. If not, I may increase drives until it has so many large files it still runs out of inodes. I suspect it adds inodes when I expand the file system tho and I can adjust without worrying about it. I just have to set it when I first create the file system I guess. This is my current drive setup. root@fireball / # pvs -O vg_name PV VG Fmt Attr PSize PFree /dev/sda7 OS lvm2 a-- <124.46g 21.39g /dev/sdf1 backup lvm2 a-- 698.63g 0 /dev/sde1 crypt lvm2 a-- 14.55t 0 /dev/sdb1 crypt lvm2 a-- 14.55t 0 /dev/sdh1 datavg lvm2 a-- 12.73t 0 /dev/sdc1 datavg lvm2 a-- <9.10t 0 /dev/sdi1 home lvm2 a-- <7.28t 0 root@fireball / # The one marked crypt is the one that is mostly large video files. The one marked datavg is where I store torrents. Let's not delve to deep into that tho. ;-) As you can see, crypt has two 16TB drives now and I'm about 90% full. I plan to expand next month if possible. It'll be another 16TB drive when I do. So, that will be three 16TB drives. About 43TBs. Little math, 430GB of space for inodes. That added up quick. I wonder. Is there a way to find out the smallest size file in a directory or sub directory, largest files, then maybe a average file size??? I thought about du but given the number of files I have here, it would be a really HUGE list of files. Could take hours or more too. This is what KDE properties shows. 26.1 TiB (28,700,020,905,777) 55,619 files, 1,145 sub-folders Little math. Average file size is 460MBs. So, I wonder what all could be changed and not risk anything??? I wonder if that is accurate enough??? Interesting info. Dale :-) :-)
