# Why can't un-journaled filesystems be resized?

I have yet to find an un-journaled filesystem that can be resized without data loss or intermediate conversions, and I'm wondering why that is.

Filesystems like FAT, for example, leave free space at the end of the block device; it seems pretty simple to me to just add more free space onto the end...

Edit: It seems that some filesystems, created without a journal, can still be resized. I created an EXT4 filesystem with mke2fs -t ext4 -O ^has_journal /dev/loop0p1, grew the partition, and successfully resized it. I also created an EXT2 filesystem (which to my knowledge doesn't have a journal) and successfully resized it.

My current theory is that it's just a big coincidence that most filesystems without a journal can't be safely resized and most with a journal can.

It’s just historical.

Old file systems are not journaled, and they cannot be resized. At some point in time journaling was added, and at some point in two resizing was added. So new file systems have both features.

You obviously don’t need the ability to resize a disk to implement journaling, but there is also no reason why journaling would be needed for resizing a hard drive.

It would be good if the file system was designed in such a way that resizing can be done with a minimal amount of moving files, and in such a way that the disk is a valid (old size) disk for as long as possible, so that only one final change is needed to change it from old size to new size.

The "file allocation table" (which gives the FAT filesystem its name) is a fixed-size array "statically allocated at the time of formatting." Its size is determined by the size of the partition, because "The table contains entries for each cluster, a contiguous area of disk storage." (quoted from Wikipedia).

So if the partition is made larger, the FAT has to be made larger. But in order to do that, whatever pieces of files which happen to occupy the sectors adjacent to the FAT need to be moved elsewhere. That's not a simple procedure, and while it is being performed, the whole filesystem is in an inconsistent state.

That might seem like a suboptimal design, but since FAT was designed for single partition removable media (i.e. floppy disks) whose size was determined at the time of manufacture, there was no need to plan for resizing. The fixed-size immovable allocation table makes for faster, simpler code.

The Wikipedia article provides a lot more details, if you're curious. It's actually not too difficult a project to write a FAT driver, which might provide additional insights.

• That makes sense. So I guess other non-journaled filesystems (like MFS and HFS, not HFS+) have the same issue? I can't seem to find the specs for either but I also don't see any mention of resizing them. Mar 16 '20 at 23:41
• @atlief: or at least similar issues; I don't remember all the details any more.
– rici
Mar 17 '20 at 0:01
• (Historical note: the data capacity of magnetic media without manufactured tracks was determined at formatting much more than at manufacture. At least Microsoft lumped the step defining physical records with initialisations like file system and (intervening?!) partition table.) Mar 17 '20 at 5:23