ext3 or ext4 support in FreeMiNT?

[leech]

I've been looking around the forums for an answer to this, but couldn't find much more than an updated e2fsprogs that supports ext4, but it also mentioned that the FreeMiNT kernel doesn't support anything above ext2. I've ran into (too many times now) a nice lockup, in which case the ext2 file system is found unchecked and so e2fsck is forced to run, and it also has locked up on me (weird thing is the first two times it ran, it at least had the progress bar, now it doesn't even show that, and I can only tell it's still doing something by watching the disk activity light flash).

So I'd like to know how we can get the journaling filesystems on the Atari! So many improvements from ext2 to ext3/4.

Maybe we can start doing AROS style bounties for things like this? I really would love to get into programming more, but haven't had the time (too many side projects), so some sort of bounty system I think would be useful.

What does everyone think?

[AdamK]

I doubt e2fsck locked, it takes a loooooong time to check big filesysytem.

[leech]

I'll agree with that. Which is why I would love it if we were able to get journaling support in the kernel driver. I do need to get the percentage of completion for e2fsck working again so I know when it's locked up or not.

I'm checked the script that kicks off the e2fsck check and -C is still in there, so I'm not sure why the progressed stopped showing.

[Eero Tamminen]

Btw. People often have unrealistic expectations from journaling file systems. Ext3/4 by default journal just file system *meta*-data because journaling also file data is way too slow for people, even with today's fast disks. And to be sure that even that journal is safe, file system expects disk to behave in certain way which I think is guaranteed only for enterprise HW, not for consumer HW.

So people who expect things to be fine when they just turn of the power without proper unmount/shutdown, some day find out that their file contents have been corrupted although they used journaling file system....

[leech]

Ah yes, I do understand this. But it's not just the journaling I'd like, but some of the other nice features (not to mention speed) of the newer versions of ext. Though I'm not sure how much more hardware (memory/cpu) overhead they'd have. I guess using these filesystems wouldn't really matter if we at least had support for some filesystems that worked better for MiNT. I haven't tested out the Minix one, but EasyMiNT mostly wanted ext2, which is pretty ancient now (granted we are talking about old computer systems...)

[wongck]

I normally have 256MB for ext2 fs and 30+ GB for FAT32.
e2fsck checking for 256MB not too bad.
You don't need so much space for e2fs applications, rather I do not use so much.
Mostly can use FAT32 partition.

[leech]

Wasn't sure what the purpose of FAT32 was, you still have to have FreeMiNT loaded for that, right? TOS itself can't access it?

[wongck]

yeap, all on Mint.
Just that the rest of the HDD is used up rather than wasted, so I make the rest of it FAT32.
Using it rather than GEMDOS for my stuff, as FAT32 supports long file names, better to classify stuff on the HDD.
Sure you can just make use of ext2 fs for doing that, but then your e2fsck at startup just makes bootup slower..... imagine e2fsck 30+ GB work be a bit slower than 256MB.

[joska]

Another advantage of FAT32 is that you can use huge partitions without the compatibility issues with ext2. Lot of GEM-software makes assumptions about file name case, which can cause a bit of head-scratching when using case sensitive filesystems like ext2. I only keep the "unixy"-stuff on ext2 and everything else on FAT-partitions.

[leech]

Well, I currently have a 128GB IDE SSD drive in the Falcon, and I have two ext2 partitions. EasyMiNT required one, and I just happen to split it up (usually in Linux world, I like to have a separate /home, though I guess it doesn't really make sense here.)

Maybe I'll look into formatting that other partition into Fat32. I could have sworn I told hddriver to byteswap the partition so that Linux could read it on my main system, but I haven't been able to get anything off of it/copy anything to it since I formatted it on the Falcon.

[wongck]

my guess is that 128GB SSD would be as fast as my 30GB hdd when attached to the falcon, as it's going at PIO-1 or PIO-2 only.

[leech]

Ha, yes, I'm well aware of that. I just wanted something a bit bigger than the 8GB CF card that I bought it with, and that drive was laying around from a failed experiment in getting it working on my Amiga A4000D.

[PeterS]

I asked about ext3 and 4 on the mint list several years ago but I don't think it was answered.

It would be a big improvement to have the xfs updated to support journalling. Should the machine crash it takes far too long to check the fs on even modest partitions and in most cases there are no issues to fix.

The xfs driver was probably ported from the ext2 sources many years ago so I expect the knowledge may have gone but a re-port of ext4 should be possible.

[PeterS]

@mods
maybe this can be moved to the Freemint section now ?

I was thinking about this again yesterday.

https://opensource.com/article/18/4/ext4-filesystem

What are current thoughts on ext3/4 for freemint ?

[ThorstenOtto]

Journal support needs also support from the kernel, which does not exist. And most other features of ext3/ext4 are only targetted at really huge devices, requiring 64bit support for all file operations. None of the internal interfaces currently support that, and it would slow down things quite a lot i guess.

[PeterS]

Ext4 is supposed to be faster but that probably assumes fast hardware so it may cancel out. The journal would help when booting after a crash etc.

[PeterS]

Maybe someone has linux or bsd running on Atari (68060) hardware that could comment on the ext4 performance?

[ThorstenOtto]

Yes, journal would be useful, but it would require years to implement that.

Maybe ext4 is faster on large devices, because some of the features are just there to avoid large seeks. On smaller filesystems (less than several 100 GB), or on SD/CF-cards, that doesn't make a difference. Also, with modern hardware, its mostly the transfer to/from memory that is the limiting factor.

But afaik, most the kernel driver is based on the standalone ext2fsprogs package, so go ahead try to implement ext3/4 using a newer version

[PeterS]

Low level kernel stuff is well outside my skillset unfortunately.

[mfro]

Have serious doubts that ext4 would be any faster than ext2 on MiNT (probably rather the opposite as CPU and disk load will increase). ext[234] filesystems are basically all the same, they just have different so-called "capabilities". ext[234] is designed for easy up- and downgrade (provided you don't violate the size limits of the target file system type) any (unmounted) ext[234] filesystem into each other type without any data loss.

Basically, ext3 is ext2 with a journal. The journal would probably make file system checks faster, but at the expense of slower normal operation (as you have to maintain the journal in addition).

ext4 is ext 3 with the additional capabilities "extents" (allocate larger chunks for large files in one piece for less fragmentation), "uninit_bg" (additional checksums) and "dir_index" (faster lookup for large directories). I don't think any of these features would help our poor m68k performance-wise as all of these features have mainly been designed with large (TB sized) filesystems and files in mind.

"tune2fs -j" makes ext3 from ext2, "tune2fs -O extents,uninit_bg,dir_index" makes ext4 from ext3. If you mark the capabilities with "^", this will also work downwards, e.g. "tune2fs -O ^has_journal" will make ext2 from ext3.