mkefs produces corrupt fs?

bridged with qdn.public.devtools
Post Reply
Kevin Kahl

mkefs produces corrupt fs?

Post by Kevin Kahl » Thu Sep 18, 2003 7:27 am

I hope I haven't tripped over an FAQ, here but...

I'm using self-host 6.2.1a PE.

Using a build file of:
[block_size=128k, spare_blocks=1]
Makefile

I do the following:
mkefs -v <buildfile> hello.efs
slay devf-ram ## (Confirmed no devf-ram instances running)
rm /dev/shmem/fs0 ## (Clean out any persisted flash file system
info)
/sbin/devf-ram -v &
cp hello.efs /dev/fs0 ## (I've also tried /dev/fs0p0)

The result is verbose console output from devf-ram:
devf: fs0p0 corrupt U: 02
devf: fs0p0 raw U: 0E

What am I doing wrong?

-- Kevin

Dave Green

Re: mkefs produces corrupt fs?

Post by Dave Green » Thu Sep 18, 2003 12:38 pm

Hi Kevin,

The devf-ram driver uses a block size of 64k for DRAM
based flash filesystems. Try setting the block size
to 64k in your build file.


Kevin Kahl <kkahl@gte.net> wrote:
I hope I haven't tripped over an FAQ, here but...

I'm using self-host 6.2.1a PE.

Using a build file of:
[block_size=128k, spare_blocks=1]
Makefile

I do the following:
mkefs -v <buildfile> hello.efs
slay devf-ram ## (Confirmed no devf-ram instances running)
rm /dev/shmem/fs0 ## (Clean out any persisted flash file system
info)
/sbin/devf-ram -v &
cp hello.efs /dev/fs0 ## (I've also tried /dev/fs0p0)

The result is verbose console output from devf-ram:
devf: fs0p0 corrupt U: 02
devf: fs0p0 raw U: 0E

What am I doing wrong?

-- Kevin
--

David Green (dgreen@qnx.com)
QNX Software Systems Ltd.
http://www.qnx.com

Kevin Kahl

Re: mkefs produces corrupt fs?

Post by Kevin Kahl » Fri Sep 19, 2003 7:49 pm

The devf-ram driver uses a block size of 64k for DRAM
based flash filesystems. Try setting the block size
to 64k in your build file.
Yes, I see now that it is an alignment problem. Thanks.

I do notice, however, that the driver seems to pick a block size depending
on how big of a RAM allocation it's given (via -s argument). I have been
unsuccessful in my attempts to take control of this (again, via 5th
parameter to -s argument) and the documentation is quite sketchy.

It should also be noted that I originally stumbled upon this problem merely
by following the instructions of the text in the Neutrino bookset
documentation, in the section dealing with building and embedded filesystem.
Those instructions clearly specify a 128k block size but give no indication
that the devf-ram driver defaults are any different. Very confusing indeed.

Finally, a separate gripe is that it's unclear to me (even after reviewing
the docs) what the expected behavior of devf-ram is if no -s switch is
supplied. It appears that a 1M region is reserved with a 16k blocksize (not
64k). Again, it'd be nice if the docs were informative here.

-- Kevin

Post Reply

Return to “qdn.public.devtools”