Hi,
I use my flash disk only in linux environment. So I would like use jffs2
filesystem on it. Is it possible ? It works like a charm on my linux-enabled
iPAQ.
I have 2.4.26 and 2.6.6 kernel vanillas running on i386 architectures.
Any patch exits ? And is including of this filesystem expected?
Thanks for reply
Michal
On 04.06.2004, at 10:00, Michal Semler wrote:
> I use my flash disk only in linux environment. So I would like use
> jffs2
> filesystem on it. Is it possible ? It works like a charm on my
> linux-enabled
> iPAQ.
> I have 2.4.26 and 2.6.6 kernel vanillas running on i386 architectures.
> Any patch exits ? And is including of this filesystem expected?
JFFS2 is included in the standard kernels IIRC, however I'd recommend
using the CVS version from the official repository as there are huge
improvements in there.
To use it on a non-MTD[1] device you will need an emulation layer,
the pseudo Block-MTD device. And you will need some additional partition
using ext2/ext3/reiserfs/FAT containing the kernel for your Grub/LILO
bootloader.
[1] Memory technology devices, e.g. flash chips soldered on some board
with direct access
Servus,
Daniel
On Fri, 2004-06-04 at 11:02 +0200, Daniel Egger wrote:
> JFFS2 is included in the standard kernels IIRC, however I'd recommend
> using the CVS version from the official repository as there are huge
> improvements in there.
JFFS2 in the 2.4 kernel is an old stable branch.
The code in 2.6 and in CVS is much faster to mount, especially, and it
also supports NAND flash.
Linus' tree is updated periodically when I'm sufficiently happy with the
stability of the development tree in CVS, and when I have time to merge
it, test it and read through all the changes for sanity -- which often
involves redoing some of them. You should be OK using what's in the
kernel -- let me know if you have problems.
> To use it on a non-MTD[1] device you will need an emulation layer,
> the pseudo Block-MTD device. And you will need some additional partition
> using ext2/ext3/reiserfs/FAT containing the kernel for your Grub/LILO
> bootloader.
JFFS2 on blkmtd isn't ideal -- it's designed to work on real flash. But
it works. It could do with someone making it use the stuff we did for
NAND -- batching writes into 512-byte chunks etc.
--
dwmw2
On 05.06.2004, at 01:09, David Woodhouse wrote:
> Linus' tree is updated periodically when I'm sufficiently happy with
> the
> stability of the development tree in CVS, and when I have time to merge
> it, test it and read through all the changes for sanity -- which often
> involves redoing some of them. You should be OK using what's in the
> kernel -- let me know if you have problems.
The original version in the 2.4 kernel has a dramatic problem
leading to FS corruption, at least when used with blkmtd on CF.
That's why I'm using 2.4 and a CVS snapshot, not only because
it is much faster.
>> To use it on a non-MTD[1] device you will need an emulation layer,
>> the pseudo Block-MTD device. And you will need some additional
>> partition
>> using ext2/ext3/reiserfs/FAT containing the kernel for your Grub/LILO
>> bootloader.
> JFFS2 on blkmtd isn't ideal -- it's designed to work on real flash. But
> it works. It could do with someone making it use the stuff we did for
> NAND -- batching writes into 512-byte chunks etc.
Believe it or not but JFFS2 is the only filesystem that works
reasonably on CF, especially when the system is used mostly read
only and the device is cut off from power every now and then. ;)
I tried different FS which we used read-only (and remounted it
r/w in case we needed it) in the last tries but we still were
able to kill a card without a problem and had FS corruption which
needed a console to fix.
Servus,
Daniel
On Sat, 2004-06-05 at 10:27 +0200, Daniel Egger wrote:
> The original version in the 2.4 kernel has a dramatic problem
> leading to FS corruption, at least when used with blkmtd on CF.
> That's why I'm using 2.4 and a CVS snapshot, not only because
> it is much faster.
Can you be more specific? I don't know of any such problems. If they
exist, they give me a potential excuse to update 2.4 to the current code
-- but to be honest I'd rather just leave it in maintenance mode.
> Believe it or not but JFFS2 is the only filesystem that works
> reasonably on CF, especially when the system is used mostly read
> only and the device is cut off from power every now and then. ;)
CF is bog-roll technology. I wouldn't want to use it in production even
with JFFS2 on it -- but at least when it gets confused you'll only lose
a limited amount of data with JFFS2.
If you're going to use JFFS2 on CF, you should really investigate using
the write-buffer we implemented for NAND flash, but without the ECC
parts. It'll mean you write each CF sector once rather than overwriting
the sector each time you add a few bytes to the log.
--
dwmw2
On 05.06.2004, at 10:46, David Woodhouse wrote:
> Can you be more specific? I don't know of any such problems. If they
> exist, they give me a potential excuse to update 2.4 to the current
> code
> -- but to be honest I'd rather just leave it in maintenance mode.
Unfortunately not. We had misterious kernel oopses on bootup in
changing places in the source that appeared and vanished at will.
At first I had broken memory in mind but this wasn't the case. My next
guess was that the log checking (the looong version) might temporarily
overheat the passively cooled CPU but we could scrap that possibility as
well after reproducing the problem in a very cool environment.
After the tedious upgrade to the CVS version, everything works
like a charm and is now in never-touch-a-running system mode.
> CF is bog-roll technology. I wouldn't want to use it in production even
> with JFFS2 on it -- but at least when it gets confused you'll only lose
> a limited amount of data with JFFS2.
Works fine for us.
> If you're going to use JFFS2 on CF, you should really investigate using
> the write-buffer we implemented for NAND flash, but without the ECC
> parts. It'll mean you write each CF sector once rather than overwriting
> the sector each time you add a few bytes to the log.
Sounds good though not too useful for us because we typically do not
write much on the disc, just the configuration which only changes
once in a while.
However, do you have any specific pointers where to look?
Servus,
Daniel
On Sat, 2004-06-05 at 15:38 +0200, Daniel Egger wrote:
> On 05.06.2004, at 10:46, David Woodhouse wrote:
> > If you're going to use JFFS2 on CF, you should really investigate using
> > the write-buffer we implemented for NAND flash, but without the ECC
> > parts.
> However, do you have any specific pointers where to look?
fs/jffs2/wbuf.c has most of the magic for buffering writes on NAND
flash. We want to use that, but we want to avoid the ECC handling which
we also do on NAND flash.
The other thing that'll benefit you is checkpointing, which I keep
threatening to implement but haven't yet got round to.
--
dwmw2
On Sat, 5 June 2004 18:01:21 +0100, David Woodhouse wrote:
> On Sat, 2004-06-05 at 15:38 +0200, Daniel Egger wrote:
> > On 05.06.2004, at 10:46, David Woodhouse wrote:
> > > If you're going to use JFFS2 on CF, you should really investigate using
> > > the write-buffer we implemented for NAND flash, but without the ECC
> > > parts.
>
> > However, do you have any specific pointers where to look?
>
> fs/jffs2/wbuf.c has most of the magic for buffering writes on NAND
> flash. We want to use that, but we want to avoid the ECC handling which
> we also do on NAND flash.
It's relatively simple to adjust. Took me two weeks to tweak it for
some "interesting" piece of NOR-Flash:
http://mhonarc.axis.se/jffs-dev/msg01402.html
The above Works For Me (tm), but is really ugly. Someone should clean
it up and merge it into cvs someday. Maybe it's useful for you.
J?rn
--
To recognize individual spam features you have to try to get into the
mind of the spammer, and frankly I want to spend as little time inside
the minds of spammers as possible.
-- Paul Graham
Daniel Egger wrote:
> Believe it or not but JFFS2 is the only filesystem that works
> reasonably on CF, especially when the system is used mostly read
> only and the device is cut off from power every now and then. ;)
>
> I tried different FS which we used read-only (and remounted it
> r/w in case we needed it) in the last tries but we still were
> able to kill a card without a problem and had FS corruption which
> needed a console to fix.
Can you give more detail on how you were able to "kill a card".
Were there hot spots in those filesystems?
P?draig.
On 08.06.2004, at 11:31, [email protected] wrote:
> Can you give more detail on how you were able to "kill a card".
Write to it every now and then using a touchy filesystem
like ext2 and it will certainly break.
As soon as a CF card starts developing bad blocks you better
(trash-)can them because they're losing reliability very
quickly.
> Were there hot spots in those filesystems?
Yes, the only place that is written every now and then is
the configuration in /etc, everything else is mostly read.
Of course with ext2 such changes will always end up in the
same physical place on disk which can chew up the few 10K
to 100K guaranteed writes last for just a really short
amount of time.
There're a few more problems with ext2/3 which make it a
rather unpleasant filesystem for often rebooted systems
with r/w mounted partitions on limited write-cycle media.
Although JFFS2 on CF seems like a kludge at first it works
much better than expected and never let us down so far
(after changing to CVS, that is!) and makes it the top
choice for quite a number of applications that want to use
spindleless drives and need some (cheap) amount of capacity.
Servus,
Daniel
In article <[email protected]> you wrote:
> Although JFFS2 on CF seems like a kludge at first it works
> much better than expected and never let us down so far
Of course, using ramdisks is the preffered method if possible (i.e. if
enough ram and if not much persistent info)
Bernd
--
eckes privat - http://www.eckes.org/
Project Freefire - http://www.freefire.org/
On Sun, 13 June 2004 10:39:05 +0200, Daniel Egger wrote:
> On 08.06.2004, at 11:31, [email protected] wrote:
>
> >Can you give more detail on how you were able to "kill a card".
>
> Write to it every now and then using a touchy filesystem
> like ext2 and it will certainly break.
>
> As soon as a CF card starts developing bad blocks you better
> (trash-)can them because they're losing reliability very
> quickly.
In other words, there is absolutely no wear-levelling in either the
driver or the card itself. Good to know.
J?rn
--
If you're willing to restrict the flexibility of your approach,
you can almost always do something better.
-- John Carmack
On 14.06.2004, at 13:45, J?rn Engel wrote:
> In other words, there is absolutely no wear-levelling in either the
> driver
The driver would be a standard IDE driver, so no.
> or the card itself. Good to know.
I've heard rumors that some cards would do this. However
I haven't seen any indication for this yet.
Servus,
Daniel
On Monday 14 June 2004 13:45, J?rn Engel wrote:
> In other words, there is absolutely no wear-levelling in either the
> driver or the card itself. Good to know.
Yep, there is no warranty that wear levelling works by design. Use a CF card
and mount ext3. Do a bit syslog stuff on it. It will crash over time -
eXperienced Problems AFAICT.
Using jffs2 via blkmtd minimizes the trouble to a bearable point.
--
Thomas
_____________________________________________________________________
>From slash dot org
"When customers are visiting, engineers are not allowed to wear ties.
That way the customer can tell who is the engineer and who is the
salesman (and therefore whom to believe.). Ties cut off blood flow
to the brain, making it easier for the salesmen to do their jobs."
_____________________________________________________________________
linutronix - competence in embedded & realtime linux
http://www.linutronix.de
mail: [email protected]