JFFS2 on block devices

Hi! I am using jffs2 just for the compression feature on my laptop (can't upgrade the HD right now). It seems to work fine for my needs (I created an jffs2 in a normal partition, the used the loopback device on it, then blkmtd on it, then mounted the mtdblock0 device).

I have two doubts though and couldn't find the answer anywhere ...

* What is the maximun size jffs2 supports? I am using a 300MB image. Is there a recommended minimun?
* Is it too bad to "resize my image" by appending 0xFF's to it's end?

Anyway, thanks a lot. It's brainkiller to use jffs2 this way and not intended for this, but I haven't found any other rw compressed HD filesystem that allows me to use recent kernels. And seems to work great for what i need (I was able to free 700MB of my tiny 2GB HD this way)

Regards,

Federico

The theoretical maximum is 4GiB. In practice, it'll get far too slow and take up far too much RAM before you get that far. I'm not sure what the _practical_ limit is.

The minimum is 6 erase blocks, at the moment. It reserves 5 for its garbage collection.

No, that's fine.

Out of interest, are you using the current code from CVS or the stable branch from the 2.4 kernel? The current code should mount a _lot_ faster. How long does it take to mount?

--
dwmw2

I am using the kernel version and mount time is about 15 minutes on this celeron 433. After mounting, speed and reliability are great. I'll test the CVS version today and report back!

Regards,

Federico

Hi,

If you are going to use the latest blkmtd from CVS it *should* be ok but note that the only testing I have done on it is to have two devices mounted (80Meg file via loopback and 80mb disk partition) then do a loop of 30 kernel rebuilds (with -j2) in parallel (takes about 24 hours on my laptop)

I would definitely advise that you make a backup of your jffs2 file somewhere as Im not sure the latest code has been that well tested by others.

cheers
si

Good tip :) ... I witnessed two halts and one crash with latest CVS snapshot (11/1) ...

One halt on the first to mount the fs, after issuing mount, I stopped the process (with ctrl-z) and then sent it to the background (bg 1). At that point the machine locked up.

After a reboot I mounted it, but starting it directly as bg process and everything was fine. After that, I umounted it and remounted it to do some testing. And finally, umounted it again, and the computer froze.

The last problem was a single mount, and on next umount i got this:

Unmounting loopback JFFS2 filsystem...

Unable to handle kernel paging request at virtual address 921c3912
*pde = 00000000
Oops: 0000
CPU:    0
EIP:    0010:[<cc90fc32>]    Not tainted
EFLAGS: 00010282
eax: 921c390e   ebx: 921c390e   ecx: cb529e20   edx: ffffff67
esi: c8a497a0   edi: 00000000   ebp: c7a35ccc   esp: c3eddef4
ds: 0018   es: 0018   ss: 0018
Process umount (pid: 187, stackpage=c3edd000)
Stack: c8a49680 c3eddf44 c7a35c68 00000000 cc914ac8 c7a35ccc c8a497a0
c0149d79
       c8a49680 c8a49680 c0149e04 c8a49680 c3eddf44 c3eddf44 c0149f40
c3eddf44
       c7a35c00 c7a35c44 cc919080 cc9190c4 cb516d68 c8a492c8 c013b27f
c7a35c00
Call Trace:    [<cc914ac8>] [<c0149d79>] [<c0149e04>] [<c0149f40>]

[<cc919080>]
[<cc9190c4>] [<c013b27f>] [<c014bd16>] [<c013f2ac>] [<c014c46b>]
[<c01278c2>]
[<c014c484>] [<c0106f73>]

Code: 8b 5b 04 50 e8 19 e1 ff ff 83 c4 04 85 db 75 ee 8b 46 24 85
 /etc/rc.d/rc.jffs2: line 35:   187 Segmentation fault      umount

$destdir
blkmtd: Device or resource busy
ioctl: LOOP_CLR_FD: Device or resource busy

The syslog always warns about (both CVS and kernel versions):

Jan 12 20:51:10 fede kernel: blkmtd: erase: invalid erase request
0x2000D @ 0x14
5E8463
Jan 12 20:51:10 fede kernel: blkmtd: erase: invalid erase request

0x2000D @ 0x14
5C8456

I suppose it's normal.

That's about it. Haven't experienced any problem after a sucessfull mount (except when trying to umount on some cases).

My humble startup script look as follows:

<<< /etc/rc.d/rc.jffs2

#!/bin/bash
srcimage="/var/compressed/volume0"
destdir="/mnt/z01/"
action=$1
mode=$2

if [ "$2" == "ro" ] ; then
$options=" -r "
fi

case "$action" in
start)
echo "Mounting loopback JFFS2 filesystem ..."
if ! grep -q mtdblock /etc/mtab ; then
losetup /dev/loop0 $srcimage
modprobe blkmtd device=/dev/loop0
nice -n 19 mount -t jffs2 $options /dev/mtdblock/0 $destdir
fi
EXITCODE=0
;;
stop)
echo "Unmounting loopback JFFS2 filesystem..." umount $destdir
rmmod blkmtd
losetup -d /dev/loop0
EXITCODE=0
;;
restart|reload)
$0 stop $2
$0 start $2
EXITCODE=$?
;;

esac

Hi,

Could you run this through ksymoops please?

No, that looks bad ;). The request is len @ offset and the length should be the same as an eraseblock. Thats looks like 128k+13bytes at an offset not aligned on a 128K boundary.

What erase size did you use in the mkfs.jffs2? By default blkmtd uses an erase size of 128K so the jffs2 image needs to match this.

Could you try running the mtd_debug (or einfo) from the utils dir (in CVS) to see what that reckons the erase regions look like?

I expect the real problem is that you are using a new and experimental blkmtd with the latest jffs2 code. It might be best to just try one of these at a time. I would suggest to go back to your clean kernel but copy the blkmtd.c from cvs into it to try that out.

The other thing to try is creating a small (8 or 16meg) jffs2 image file and mounting/unmounting that in loopback with CONFIG_MTD_DEBUG set to 2 (note this will generate a *lot* of syslog output). Feel free to mail this to me privately so as not to spam the list (or post a link to it).

What base kernel version are you using?

cheers
si