OK, I am currently sitting here patiently (yea right) waiting for my relatively small 40Gig empeg to complete an fsck after a failed sync. I have been waiting for about 15 minutes and I figure it will take at least another 15 minutes to complete. It occurs to me that this sucks. What about a journaling filesystem? I know that has been brought up before, but I though it might be nice to think about it again. All we need is kernel support for it right? The two leading JFS for linux right now are ext3 and reiser right? Have either of these been backported to the 2.2 kernel series? It just seems like with all the very bright people on this board doing stuff like hijack, dsp programming, etc. there ought to be somebody interested in and capable of getting this to work. Anybody? Anybody? Bueler? Bueler?

In another recent thread, I seem to recall one of the empeg guys saying that if they were going to port a journaled filesystem to the car player, it would probably be Ext3 instead of Reiser due to the ease of migration. No specific timetable was given for this.

No specific timetable was given for this.

Personally I am not expecting the empeg guys to ever do this which is why I mentioned it in this forum rather than as a feature request. They are obviously busy working on other projects and this is something that could easily be done by the community here since it has nothing to do with the core empeg software. If/when the empeg guys do find more time to work on the car players I think there is a lot of better ways for their effort to be spent (voice recognition, ogg support, bug fixes, etc).

-Mike

Personally I am not expecting the empeg guys to ever do this

I don't see how it's going to get done unless they do it.

Well, okay, it could get done by people other than the empeg guys if (a) the player app gets opensourced, or (b) someone writes a replacement player app, builder image, and upgrader.

I don't see how it's going to get done unless they do it.

Well, okay, it could get done by people other than the empeg guys if (a) the player app gets opensourced, or (b) someone writes a replacement player app, builder image, and upgrader.

Why would any of that need to happen? The filesystem is totally on OS level thing and the empeg software shouldn't care about it at all. Users could run a jfs on the music partitions and leave everything else alone. That way the empeg upgrades should still work as always. After installing the empeg software the user would need to update the kernel and probably a few userland utilities (fsck, mount, etc). The process shouldn't be any harder than installing any of the current userland apps people have created. The only empeg software that shouldn't "just work" with jfs formatted music partitions is the builder utility which isn't really necessary.

-Mike

Why is it that I feel partially responsible for you hating fsck? Curiously, jEmplode has a bug and moments later you're talking about fscking

Nah, I have always hated fsck. Every once in a while jemplode does remind me of that though ;-)

Nope, all it would really take is for someone to backport ReiserFS properly, or port the empeg-car drivers to 2.4. The code in 2.2 was broken for non-X86 systems as I found out when I expermented with this idea here. The player and upgrader apps should still be fine. After upgrades, it would be vital to get the replacement kernel on for the player app to stop having issues reading the database and music.

i love jemplode! YAY!!!!!!!!!!

Nope, all it would really take is for someone to backport ReiserFS properly, or port the empeg-car drivers to 2.4

What about going to ext3 instead? I found ext3 patches for as far back at linux-2.2.19 (empegs kernel is 2.2.14). I played with it a little bit and couldn't get them to patch cleanly against the empeg tree, but somebody more familiar with the kernel than I am might be able to. Or we could try to get the empeg tree up to 2.2.19 and go from there. Anybody know if ext3 from that long ago (it is version 0.0.7a) would even work on an arm platform? It seems like this would be less work than getting all the empeg changes ported up to 2.4.

-Mike

Greetings!

You haven't lived until you have gotten a surprise FSCK on a pair of 60's... 90 minutes later...

It's going to be a lot easier to patch the empeg's kernel to a later 2.2 and add ext3 than it is going to be to move to 2.4 - mainly due to memory management issues.

Worst-case, you'd just need a dummy fsck to fool the player software - but no software changes *should* be required... I think. Well, if anything the changes would just be to the init and not the actual player.

Hugo

you'd just need a dummy

The player does need to know, unfortunately; it's responsible for unmounting and remounting around a fsck and so must know the FS type. Currently (because the same code is used on the Rio Central) it knows about ext2 and ReiserFS but not ext3.

Peter

Naw, it doesn't need to know. If it thinks it needs to know (bad programming, IMHO), then we can simply have the kernel lie to it, reporting ext2 instead of ext3.

Cheers

It's not the reporting that's the issue. It's the call to mount(2).

It's not the reporting that's the issue. It's the call to mount(2).

I guess we could use getmntent(/etc/fstab). Currently we examine the superblock magics directly, which seems more robust as it doesn't rely on /etc/fstab changing in sync with the filesystems. This won't, however, work for ext3, as it has the same superblock magic as ext2.

Peter

Is the regular "auto" setting (for fstab entries) actually handled by mount(8), or by the kernel? If the latter, then.. do what "auto" does. Probably the former, though.

For the current software, we could have Hijack simply correct things in the mount() call for ext3.

Cheers

OK, I made just a little progress on this today. I got a very old ext3 (0.0.2d) to patch onto the empeg kernel tree and compile. I also got updated e2fsprogs compiled. Amazingly enough it boots and seems to work as expected with ext2 partitions. I was able to create a journal file for an existing ext2 partition as well as format a partition fresh as ext3. Unfortunately I can't mount the partitions. I get this error...

empeg:/# mount -t ext3 /dev/hda4 /test
attempt to access beyond end of device
03:04: rw=0, want=2147483632, limit=9737280
dev 03:04 blksize=4096 blocknr=-5 sector=-40 size=4096 count=1
JFS: no valid journal superblock found
EXT3-fs: error loading journal.
attempt to access beyond end of device
03:04: rw=1, want=2147483632, limit=9737280
dev 03:04 blksize=4096 blocknr=-5 sector=-40 size=4096 count=1
EXT3-fs: get root inode failed
mount: wrong fs type, bad option, bad superblock on /dev/hda4,
or too many mounted file systems

If I am reading that right it is trying to read way past the end of the partition. I don't know if this old of an ext3 is actually supposed to work on an arm architechture so maybe I am having endianness issues and am just SOL? I think my next step is to try to patch up to a later version of the ext3 stuff. Any other ideas?

-Mike

maybe I am having endianness issues and am just SOL

Maybe you are having alignment issues and are just SOL. The ARM cannot load a 32-bit quantity from a non-4-byte-aligned address correctly (it silently gives the wrong answer). This often comes as a surprise to x86-trained kernel developers; in particular it took me a lot of hacking on ReiserFS to work around those issues in 2.2.

Peter

Maybe you are having alignment issues and are just SOL

Fair enough. When you where working with Reiser did you ever look at ext3? I am curious as to how current I would have to get it to work on an ARM, but I haven't found any info with a few google searches.

-Mike

When you where working with Reiser did you ever look at ext3?

No, it didn't really exist in those days. A bit of googling turned up an 0.07 for 2.2, which sounds a bit more modern than your 0.02d. I haven't found a definite answer either way about ARM compatibility, but I doubt they'd have accepted it for 2.4 stable if it only worked on x86.

Peter

Cool, thanks for looking. I tried .07 also, but couldn't get it to patch against 2.2.14. I am probably in over my head at this point as it looks like I would have to get the empeg kernel tree patched up to at least 2.2.19 before .07 is going to work :-(

-Mike

OK, baby steps here. The good news is I managed to patch the empeg tree up to 2.2.15 getting me just a little closer to my goal of 2.2.19. The bad news is it took about 3 hours and I broke ir in the process :-(

-Mike

The bad news is it took about 3 hours and I broke ir in the process :-(

Yup, that's pretty much what happens when we upgrade the kernel, too.

Peter

Yup, that's pretty much what happens when we upgrade the kernel, too.

ROFL. Thanks, that makes me feel better

Just incase anybody cares I am patched up to 2.2.17 and everything except IR still seems to work. If I get some more time to work on it tomorrow I might actually hit 2.2.19.

BTW, Peter, do you have any suggestions on getting IR working again? With 2.2.15 I got an error message saying something like "EmpegIr:Init Failed". With the more recent versions I don't even get that, but my remote does not work

-Mike

Getting ext3 working would be fantastic...Good luck! But on the subject of "fsck sucks", I'd just like to point out that it absolutely rocks compared to scandisk.exe. Admittedly the reason for that probably has more to do with the underlying fs type, but hopefully you get my point..

Would that be like...

fsck sucks, but scandisk swallows

First time I saw that comparison was at a paintball tournament - "Losings sucks" shirts were popular, but one team had made their own stating "but cheating swallows" mainly as a comment on the attitudes of the teams wearing the "Losing sucks" version.

/Michael

I have just one thing to say.....

empeg:/# mount -t ext3 /dev/hda4 /test
EXT3-fs: recovery complete.
empeg:/# cat /proc/mounts
/dev/root / ext2 ro 0 0
/dev/hda2 /scratch ext2 rw,sync 0 0
none /proc proc rw 0 0
/dev/hda4 /test ext3 rw 0 0
empeg:/# echo "fsck sucks ;-)" > /test/testfile

It works! I don't know how stable it is going to be since it is still really out of date. I couldn't get the kernel upgraded past 2.2.17 w/ ext3 0.03b, but that was far enough to get it working. I am going to be out of town for the weekend, but when I get back I will try to put together instructions and a kernel patch. At that point I am going to need Mark Lord's help with faking out the player software to mount it properly. I am going to go have a celebratory beer now.

Yeah,
-Mike

Oh, and IR is still broken :-(