8

I have a small "rescue" system (16 MB) that I boot into RAM as ramdisk. The initrd disk that I am preparing needs to be formatted. I think ext4 will do fine, but obviously, it doesn't make any sense to use journal or other advanced ext4 features.

How can I create the most minimal ext4 filesystem?

  • without journal
  • without any lazy_init
  • without any extended attributes
  • without ACL without large files
  • without resizing support
  • without any unnecessary metadata

The most bare minimum filesystem possible?

Peter Mortensen
  • 1,029
  • 1
  • 8
  • 10
400 the Cat
  • 819
  • 4
  • 37
  • 85

3 Answers3

19

Forgive me for challenging your requirements, but what are you trying to achieve by switching these features off? Space on disk? Performance? ...?

I’m struggling to understand why you'd want a filesystem to be writable and not want the safety of journaling, or why you'd want to use ext4 for a read-only file system.

A small read-only SquashFS file system feels like a safer option for a recovery system and would be smaller and faster than ext4 in most cases.

Peter Mortensen
  • 1,029
  • 1
  • 8
  • 10
Philip Couling
  • 17,591
  • 5
  • 42
  • 82
  • 4
    I'm not the OP, but I have a hard drive which I wanted to use without journaling and a few other ext4 features. I elected to go the simple route of creating the filesystem as ext2 rather than ext4. My motive was to allow the use of disk erase utilities like `scrub` on the filesystem contents. – Sotto Voce Jul 23 '23 at 17:16
  • 1
    @SottoVoce just so it's stated clearly, in that situation what was your reason for disabling journaling. – Philip Couling Jul 24 '23 at 00:52
  • 1
    @SottoVoce: Wouldn't `data=ordered` instead of `data=journal` do equally well at avoiding copies of sensitive file data in the journal where `scrub` couldn't overwrite it? `data=ordered` is the default. Or do filenames ("contents" of directory inodes) count as metadata, but you want to be able to scrub those, too? Oh, and ext4 can inline small files into inodes; I guess that's something you wanted to avoid. (The `inline_data` feature, kernel 3.8) – Peter Cordes Jul 25 '23 at 14:29
  • 1
    Why one would not want journaling? Because it is actually worse than useless on a RAM disk. Journaling is crash recovery, and a crash deletes the RAM disk media, so there can be no recovery -- thus useless. And journaling has a performance impact, thus being worse. – David G. Jul 25 '23 at 14:40
  • 1
    @DavidG. That whole argument applies to ext4 generally, which was my point. If you don't want to persist changes then why use ext4 at all? Tempfs or at least a tempfs overlay would be a better option and leave ext4 out of the equation entirely. – Philip Couling Jul 25 '23 at 21:17
  • 1
    @PhilipCouling @PeterCordes This wasn't an academic exercise, it was a practical one. I needed to store sensitive data on an HD and be able to scrub the data with high confidence that, as you mention, slices of data wouldn't be left in a journal, and that the journal would not defeat the writes of different data patterns to the same disk blocks. At the time I didn't know about ext4 options like `data=ordered` and didn't have time to test them before configuring the filesystem and moving on to the next project. I chose to simply avoid potential journal issues with ext2. – Sotto Voce Jul 26 '23 at 11:39
  • @SottoVoce not suggesting it was an academic, just wanted it to be clear to future readers so they can make up their own mind about whether its relivant to them. – Philip Couling Jul 26 '23 at 15:01
17
  • Or you could simply use ext2
  • For ext4:

mke2fs -t ext4 -O ^has_journal,^uninit_bg,^ext_attr,^huge_file,^64bit [/dev/device or /path/to/file]

man ext4 contains a whole lot of features you can disable (using ^).

Artem S. Tashkinov
  • 26,392
  • 4
  • 33
  • 64
  • 1
    is ext2 basically ext4 with all the features disabled ? – 400 the Cat Jul 23 '23 at 14:30
  • 20
    @400theCat one can say ext4 is ext2 with a whole lot of features added – muru Jul 23 '23 at 14:35
  • ext4 optimizes ext2 significantly - format a 1TB volume with ext2 and ext4 and you'll instantly see the difference. ext2 will probably need ~20 times more data [metadata] on the volume to operate. We are talking about tens if not hundreds of megabytes. For very small volumes (under 100MB) ext2 might be faster (read more efficient) but someone has to test this. – Artem S. Tashkinov Jul 23 '23 at 15:17
  • 6
    ext2 has no extents, that's why it needs to much metadata for addressing blocks. It also has very low resolution time. ext4 also supports larger inode which can accommodate inline files, reduce metadata+data size and accessing time. One can use tune2fs to upgrade ext2 to ext4 without extents and larger inode, but for those features you'll have to format ext4 from scratch – phuclv Jul 23 '23 at 15:54
12

The correct answer here is to not use a ramdisk at all. Note ramdisk and tmpfs are two different things.

What you’re describing is a live system. No sane Linux live system setup has used ramdisks for years now, because it’s far better to either:

  • Just use an initramfs (an optionally compressed CPIO archive) instead. The kernel will extract the archive into a special tmpfs instance on startup (this is marginally slower than copying an initrd into a ramdisk, but even on extremely slow systems the difference is measured in miliseconds, so not worth caring about), and then run with that tmpfs instance as the root filesystem. Once running it’s actually marginally faster than using a ramdisk (no simulating a block device, no fancy filesystem driver), it will take up far less space in memory (because tmpfs is functionally just exposing the page cache as a filesystem directly), and it will auto-resize as needed (because tmpfs lives in the page cache, unlike ramdisks which have to pre-allocate space).

or:

  • Use a compressed read-only filesystem (usually SquashFS these days) which gets mounted directly (without needing a ramdisk at all), and then using an overlay filesystem (usually OverlayFS these days) on top of that to allow it to be writable. Given the very small size of your stated recovery image, this is probably not going to save you anything, but it’s the ‘normal’ approach used by most live systems these days.
Philip Couling
  • 17,591
  • 5
  • 42
  • 82
Austin Hemmelgarn
  • 11,401
  • 1
  • 24
  • 42
  • 2
    A number of Raspberry Pi live systems use ramdisks because that lets you pull the SD card out after booting. Note that these are generally special-purpose systems rather than general-purpose desktop systems. – Mark Jul 24 '23 at 22:53
  • 1
    @Mark Either of the approaches I outlined also let you pull the boot media (even on an SBC like a Raspberry Pi). And most of the RPi live images I’ve seen that aren’t using either approach I outlined are using a ZRAM block device, not a regular ramdisk (the two are very different things, though I would argue that that approach is _still_ suboptimal compared to the squashfs method). – Austin Hemmelgarn Jul 25 '23 at 11:00
  • 1
    Er... Isn't initramfs a ramdisk that's in use by live, sane system setups on every (re)boot? – Sotto Voce Jul 26 '23 at 11:42
  • 3
    @SottoVoce You seem to be confusing an initramfs with an initrd. They serve a similar purpose, but are _very_ different things for a number of reasons. A concise explanation can be found here: https://stackoverflow.com/a/10603984/8327468. Essentially all normal Linux systems these days are using an initramfs (and this has been the case for at least half a decade now) because it’s a superior design in almost all respects. – Austin Hemmelgarn Jul 26 '23 at 12:30
  • 2
    Irritatingly too many people refer to initramfs as initrd and too many people refer to tmpfs as a ramdisk. I've added a minor note to avoid that trip hazard. – Philip Couling Jul 26 '23 at 15:17