0

I intend to have a 4Tb ext4 filesystem with only 1 file. The file will fill the entire drive. The file will be an image of another journaled filesystem which I will mount and use.

What ext4 tune2fs options should I use to best optimizing performance?

Rucent88
  • 1,850
  • 4
  • 24
  • 33
  • 3
    Why bother with an ext4 file system if it’s just going to store an image of another file system? – Stephen Kitt Aug 02 '21 at 21:09
  • Ext4 is able to check and skip/avoid bad blocks on the hardware level, but many other filesystems can't do that, which is why I would like to have Ext4 as the underlying filesystem. – Rucent88 Aug 03 '21 at 09:37
  • Have you run into any storage made in the last twenty years or so where bad block lists are useful? Storage devices do their own bad block replacement... – Stephen Kitt Aug 03 '21 at 09:43

1 Answers1

1

Since you want to store a journalling file system on that, turn off journalling on the ext4 file system; the additional journal doesn't help you.

With a single file, this basically reverts the relevant feature set to ext2 (maybe with a slightly smarter handling of extents, but that really doesn't matter here).

So, the honest answer is: don't use ext4 for this use case if performance matters. Usually, you'd just instead make a volume for that file system you want to put on there and work with that - that's why Linux has a volume manager.

Things that aren't file systems don't need to be file systems.

Marcus Müller
  • 21,602
  • 2
  • 39
  • 54
  • ExtX filesystems are able to check and remove bad blocks, but many other filesystems can't do that, which is why ExtX should be the underlying filesystem. Also, the reason to use Ext4 over Ext2 is a max filesize of 2Tb. – Rucent88 Aug 03 '21 at 04:19
  • bad block detection is not a feature of ext, but of the underlying storage. This all makes no sense! – Marcus Müller Aug 03 '21 at 07:08
  • I should have wrote "ExtX filesystems are able to check and *Skip/Avoid* bad blocks". This is a filesystem feature `mkfs.ext4 -fcc device` – Rucent88 Aug 03 '21 at 09:34
  • `-fc` just checks for bad blocks upon filesystem creation; *that's still a feature of the storage, not the file system*, has only effect once (before the file system is created) and doesn't help your stored file system! – Marcus Müller Aug 03 '21 at 10:24
  • Aside from that, if your storage *reports bad blocks*, then its internal bad block replacement has failed, and the storage **is currently failing**: you should not use this storage anymore. Full stop – the next block that fails will be within your useful data, and ext4 has zero functionality to recover that data. Ext4 on ext4 doesn't change that at all – on the contrary, just one more layer of things that might go wrong, and one more read/write-heavy metadata structure to make things fail earlier. – Marcus Müller Aug 03 '21 at 10:26
  • I appreciate your help. By running `e2fsck -fcck /dev/sdc1`, then Ext4 can update it's list of known bad blocks to avoid. Why do you say that Ext4 ability to avoid bad blocks is not a feature of Ext4? – Rucent88 Aug 03 '21 at 17:07
  • but the e2fsck run just asks the underlying storage device for bad blocks (detection is not a feature of ext4). Ext4, like *very* many file systems, has a bad block list, but so does the ext4 inside your image file. Having an outer file system helps you *not at all*. If that list of bad blocks changed since the last time you run it, and one of these bad blocks is inside the image *you just lost data*; ext4 doesn't help you with that. Also, I have no idea why you specify `-c` twice in both calls – that doesn't *do* anything. – Marcus Müller Aug 03 '21 at 19:27
  • You're making several mistakes and incorrect assumptions here 1. Moving the goal post. I never claimed Ext4 has "dynamic badblock detection" (or whatever you're implying). The point is, running a fsck can detect badblocks, and avoid them. That's good enough for my purposes. 2. The "very many" number of filesystems that support badblock lists is Irrelevant. There could be 1 billion filesystems that support badblocks. I'm using a filesystem image that doesn't support badblocks. 3. I'm not using Ext4 inside the image, and I never claimed to. 4. Specifying -c twice DOES do something. Please RTFM – Rucent88 Aug 04 '21 at 05:25
  • And lastly, 5. None of this pertains to the original question, which was How to make Ext4 efficient for 1 large file. Your answer was only turn off journaling. Had you considered adjusting inodes? Or changing block size? Why get distracted on nonsense instead of the answer? This is stackexchange, not a generic forum from the 2000's – Rucent88 Aug 04 '21 at 05:25
  • You might ask, Why don't I just RTFM myself and answer the original question? 1. Because perhaps someone knows a trick or hidden information that I might not be considering. 2. To give someone like you the chance to gain some positive Karma – Rucent88 Aug 04 '21 at 05:35
  • @Rucent88 5. yes I did. And the result was that for a single file, nothing matters, turn off journalling. – Marcus Müller Aug 04 '21 at 07:09