0

I have a RHEL 9 with an ext4 fs

Device Boot Start End Sectors Size Id Type /dev/sdb1 2048 1258291199 1258289152 600G 83 Linux

it has been requested it be ext4 with Inodes for 100,000,000 files +

I thought I could just run mkfs.ext4 -N 2000000000 /dev/sdb1

to get more than enough inodes however when I mount the partition

mount /dev/sdb1 /fileshare

the /fileshare shows up as only 92gb

when I run mkfs.ext4 /dev/sdb1 then mount it the /fileshare shows as 560gb which is what I want how can I get a inode count that I need to accommodate that large file count (100 million to 500 million) but still have the 560gb disk size?

Improve this question
6
  • 4
    With the default size 256 bytes for an inode, requesting that many inodes will take up about 476GiB. Switching to a different file system will not help you very much and might hurt. You'll need a larger disk to handle 5M files. Commented Feb 22, 2024 at 16:51
  • 1
    @doneal24 I think that your comment has answer qualities! I'd upvote it if you posted it as answer. (It would also allow the discussion of whether different filesystems would behave better to be kept there.) Commented Feb 22, 2024 at 16:53
  • Why -N 2000000000? Your question says your target is around the 100 million mark, not the 2000 million mark - you're asking for 20x more inodes than you need Commented Feb 22, 2024 at 17:38
  • How big are your files (on average)? Do you have enough disk space for 100 million of them? Even at a minimum of 1kB/file you're going to need 1TB storage just for the data Commented Feb 22, 2024 at 17:50
  • 1
    @MarcusMüller I considered this as an answer but it really does not answer the OP's question on how to set the filesystem to accommodate his needs, only why his commands don't work as expected. Commented Feb 22, 2024 at 23:10

2 Answers 2

Reset to default
2

Why -N 2000000000? Your question says your target is around the 100 million mark, not the 2000 million mark - you're asking for 20x more inodes than you need. Fix that and you might get a reasonable result.

However, there is a bigger issue here with regard to file size. Although at a minimum of 1kB/file you're going to need only around 125GB storage to hold that many files (including an approximation for the inodes, at 4x per kB), if we go with your example's 2x10^9 inodes then that's going to be 2.25TB. At least.

Improve this answer
11
  • I'll argue that things get pretty specific at this number of files, and that maybe classical file systems simply are the wrong choice there; some kind of object storage might be Commented Feb 22, 2024 at 17:59
  • 2
    About 15-20 years ago I worked on a project where we captured photographs of vehicles. Between 2 and 5 photos each, and we had to keep them for a few years. A quick back-of-the-spreadsheet calculation suggests it might have been around 300,000 photos per year, and at even only 2MB/photo that's 500GB/year. We used a hierarchical directory structure simply to make it easier for our support staff to hunt through the photos. These days it might make more sense to use a bucket based solution or even a database but back then putting TB of image data into a database was questionable. @MarcusMüller Commented Feb 22, 2024 at 18:15
  • Maybe with inline data, a (very) small file would need just an inode and the direntry? The docs seem to say you could put 60 bytes in an 128-byte inode, or maybe 160 bytes in a 256-byte inode... that's still at least 60 % overhead, so perhaps some other database format could offer better space utilization... Commented Feb 22, 2024 at 19:10
  • 1
    @ChrisDavies, what, no, that wouldn't make any sense, I can't see where that idea would come from. Like the other answer says, the numbers given in the question work out for the default 256 B inodes (2*10^9 * 256 bytes =~ 500 GB). If the inodes were any bigger, they wouldn't even fit. I can't find a perfect quote from the docs, but the FS layout doc says the inode table is a linear array (though really it's split between block groups), and that "Each inode record can be as large as the filesystem block size, though this is not terribly efficient." Commented Feb 22, 2024 at 19:44
  • 1
    @LustreOne I've written things I would call "object storage" for measurement data recordings (at megasamples per second, so linearity of access was… important). Idea is ferociously simple: a simple off-device table in a file that maps recording ID to a 64bit unsigned start address and a length on a raw block device (in that case, that was an LVM2 volume); that table (I was lazy and just use sqlite, a good decision as it turns out) is the only thing you need to make atomically modifiable. That's what I had in mind when I said "object storage": a plain relational DB indexing linear memory. Commented Feb 23, 2024 at 16:36
2

You asked for 2 billion inodes which at 256 bytes per inode is 476 GB of inodes. ask for 500 million and it will be much better at only 120 GB of space for inodes. You can even shrink the size of an inode -I 128 but that comes with limitations, see the mkfs.ext4/mke2fs man page for details.

I would just use the -i bytes-per-inode option, and trust that you will get a good balance.

Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.