JFFS2 on block devices

JFFS2 on block devices

[Federico Ferreres]

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

Re: JFFS2 on block devices

[David Woodhouse]

fferreres@arrancar.com said:
>  * What is the maximun size jffs2 supports? I am using a 300MB image.
> Is there a recommended minimun?

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.

> * Is it too bad to "resize my image" by appending 0xFF's to it's end? 

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

Re: JFFS2 on block devices

[Federico Ferreres]

On Sun, 2003-01-12 at 06:21, David Woodhouse wrote:
 
> 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?

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

> --
> dwmw2
> 
> 

Re: JFFS2 on block devices

[spse]

Hi,

>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!
>


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.


>Regards,
>
>Federico

cheers
si

Re: JFFS2 on block devices

[Federico Ferreres]

On Sun, 2003-01-12 at 17:43, spse@secret.org.uk wrote:
> 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.

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



> 
> 
> >Regards,
> >
> >Federico
> 
> cheers
> si
> 

Re: JFFS2 on block devices

[spse]

Hi,

>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

Could you run this through ksymoops please?



>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.
>

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?

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

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