nftl driver

nftl driver

[Nikolai Vladychevski]

Hi, 

I have a problem, when I try to use nftla device zeros are wroten: 

dd if=/tmp/romfile of=/dev/nftla 

reports that the data was written ok,but when I do hexdump against 
/dev/nftla it has zeros. 

I use nftla_format before doing dd ,and I do not unload nftl driver (as the 
HOWTO suggests) because it is not compiled as module, it is included into 
the kernel. Actualy I use /dev/nftla for booting only and loading 
applications into a ramdisk, after that I do not access /dev/nftla anymore. 
The problem begins when I want to upgrade my software that is located on 
that device, and have to nftl_format again. If this problem of writing zeros 
is due to the module unloading problem, how can I solve it if the driver is 
in the kernel and cant be reloaded? 

Nikolai 

Nikolai

Re: nftl driver

[David Woodhouse]

niko@isl.net.mx said:
>  If this problem of writing zeros  is due to the module unloading
> problem, how can I solve it if the driver is  in the kernel and cant
> be reloaded? 

Almost certainly. The driver has lots if internal state about the old NFTL
format cached, and you've gone and changed it all. You should never need to
use nftl_format. If you want new data, just write new data to /dev/nftla. 
You don't need to do a low-level format just to change the data.

--
dwmw2

Re: nftl driver

[Nikolai Vladychevski]

David Woodhouse writes: 

> 
> niko@isl.net.mx said:
>>  If this problem of writing zeros  is due to the module unloading
>> problem, how can I solve it if the driver is  in the kernel and cant
>> be reloaded? 
> 
> Almost certainly. The driver has lots if internal state about the old NFTL
> format cached, and you've gone and changed it all. You should never need to
> use nftl_format. If you want new data, just write new data to /dev/nftla. 
> You don't need to do a low-level format just to change the data.

well, its just my application requires it .... I have to nftl_format because 
I do not nftl_format at the 0x00000. There is another data of variable 
lenght that I place before nftla data, so i have to nftl_format 
0xSOME_OFFSET that is different evry time.... 

but ... if the driver doesn't come the application , the application will 
have to go to the driver... 

Nikolai

Re: nftl driver

[David Woodhouse]

niko@isl.net.mx said:
>  well, its just my application requires it .... I have to nftl_format
> because  I do not nftl_format at the 0x00000. There is another data of
> variable  lenght that I place before nftla data, so i have to
> nftl_format  0xSOME_OFFSET that is different evry time.... 

> but ... if the driver doesn't come the application , the application
> will  have to go to the driver...  

If you can't make the NFTL driver a module, you should either reboot 
immediately after doing nftl_format, or implement an ioctl for making it 
'remount'.

--
dwmw2

jffs2_gcd_mtd4 <defunct>

[Joakim Tjernlund]

Hi all

Small bug:
When i mount a jffs2 FS as root FS I get this [jffs2_gcd_mtd4 <defunct>]
process(and a [jffs2_gcd_mtd4] process as well). This will not happen
if I mount jffs2 as a extra FS after boot(mount /dev/mtdblock4 /jffs2)

Another thing:
We are suffering somewhat from long mount times and I remember something
about checkpoints in jffs2 would solve this problem. Correct?

Anybody working on this? I would be happy to do some testing if needed.

Yet another thing:
I remember seeing something about beeing alble to control the compression
level in jffs2(at mount time?), but I can not find in the sources. Is it
implemented yet?

    Joakim

Re: jffs2_gcd_mtd4 <defunct>

[David Woodhouse]

joakim.tjernlund@lumentis.se said:
> When i mount a jffs2 FS as root FS I get this [jffs2_gcd_mtd4 <defunct>
> ] process(and a [jffs2_gcd_mtd4] process as well). This will not
> happen if I mount jffs2 as a extra FS after boot(mount /dev/mtdblock4 /
> jffs2)

Init doesn't reap children which are already dead by the time it's started. 
I think this was declared to be a bug in init itself.


> We are suffering somewhat from long mount times and I remember
> something about checkpoints in jffs2 would solve this problem.
> Correct?

> Anybody working on this? I would be happy to do some testing if
> needed. 

Many people have been talking about it. I've seen no code yet, nor even 
serious debate on the details of how to do it.


> I remember seeing something about beeing alble to control the
> compression level in jffs2(at mount time?), but I can not find in the
> sources. Is it implemented yet?

This is a lot more straight-forward, but still not yet done. 



--
dwmw2