9

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?

Improve this question
2
  • 5
    just do not use EXT3 / EXT4 then !
    – francois P
    Commented Jul 23, 2023 at 13:59
  • 26
    The "most minimalistic ext4 filesystem without journal" is an ext2 filesystem. An ext4 filesystem driver can also mount and fully access an ext2 filesystem.
    – telcoM
    Commented Jul 23, 2023 at 20:20

3 Answers 3

Reset to default
20
  • 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 ^).

Improve this answer
5
  • 1
    is ext2 basically ext4 with all the features disabled ?
    – Martin Vegter
    Commented Jul 23, 2023 at 14:30
  • 20
    @400theCat one can say ext4 is ext2 with a whole lot of features added
    – muru
    Commented Jul 23, 2023 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
    Commented Jul 23, 2023 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
    Commented Jul 23, 2023 at 15:54
  • 2
    I find disabling journal and huge files sufficient for my 128GB SD card mkfs.ext4 -O ^has_journal,^huge_file -L 128G /dev/sdb1
    – andrej
    Commented Dec 10, 2023 at 16:42
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.

Improve this answer
7
  • 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
    Commented Jul 23, 2023 at 17:16
  • 1
    @SottoVoce just so it's stated clearly, in that situation what was your reason for disabling journaling.
    – Philip Couling
    Commented Jul 24, 2023 at 0: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
    Commented Jul 25, 2023 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.
    Commented Jul 25, 2023 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
    Commented Jul 25, 2023 at 21:17
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.
Improve this answer
5
  • 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
    Commented Jul 24, 2023 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
    Commented Jul 25, 2023 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
    Commented Jul 26, 2023 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: 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
    Commented Jul 26, 2023 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
    Commented Jul 26, 2023 at 15:17

You must log in to answer this question.

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