* Re: your mail
2002-08-30 18:43 Bloch, Jack
@ 2002-08-30 18:55 ` Matthew Dharm
2002-08-30 19:22 ` Andreas Dilger
2002-08-31 0:12 ` David Woodhouse
2 siblings, 0 replies; 4+ messages in thread
From: Matthew Dharm @ 2002-08-30 18:55 UTC (permalink / raw)
To: Bloch, Jack; +Cc: linux-kernel
[-- Attachment #1: Type: text/plain, Size: 1541 bytes --]
I would simply recommend switching to ext3, where these types of errors
generally don't occur.
Oh, and if you just edit your initscripts, you can do anything you want.
Matt
On Fri, Aug 30, 2002 at 02:43:52PM -0400, Bloch, Jack wrote:
> I have an embedded system runing a 2.4.18-3 Kernel. It runs from a 256MB
> compact flash disk (emulates an IDE interface). I am using an EXT2
> filesystem. During some power-off/power-on testing, the disk check failed.
> It dropped me to a shell and I had to run e2fsck -cfv to correct this
> problem. This is all good and well in a lab environment, but in reality,
> there is nobody there to perform the repair (running system is not equipped
> with keyboard and monitor). Is there any way to invoke e2fsck automatically
> or inhibit the failure detection mechanism? Please CC me directly on any
> responses.
>
>
> Thanks in advance....
>
> Jack Bloch
> Siemens ICN
> phone (561) 923-6550
> e-mail jack.bloch@icn.siemens.com
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
Matthew Dharm Home: mdharm-usb@one-eyed-alien.net
Maintainer, Linux USB Mass Storage Driver
My mother not mind to die for stoppink Windows NT! She is rememberink
Stalin!
-- Pitr
User Friendly, 9/6/1998
[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: your mail
2002-08-30 18:43 Bloch, Jack
2002-08-30 18:55 ` your mail Matthew Dharm
@ 2002-08-30 19:22 ` Andreas Dilger
2002-08-31 0:12 ` David Woodhouse
2 siblings, 0 replies; 4+ messages in thread
From: Andreas Dilger @ 2002-08-30 19:22 UTC (permalink / raw)
To: Bloch, Jack; +Cc: linux-kernel
On Aug 30, 2002 14:43 -0400, Bloch, Jack wrote:
> I have an embedded system runing a 2.4.18-3 Kernel. It runs from a 256MB
> compact flash disk (emulates an IDE interface). I am using an EXT2
> filesystem. During some power-off/power-on testing, the disk check failed.
> It dropped me to a shell and I had to run e2fsck -cfv to correct this
> problem. This is all good and well in a lab environment, but in reality,
> there is nobody there to perform the repair (running system is not equipped
> with keyboard and monitor). Is there any way to invoke e2fsck automatically
> or inhibit the failure detection mechanism? Please CC me directly on any
> responses.
I would instead suggest using a filesystem like JFFS2 for flash devices.
This is journaled like ext3, but it also has the benefit of doing wear
levelling on the device, which otherwise will probably wear out the
superblock part of the flash rather quickly.
Cheers, Andreas
--
Andreas Dilger
http://www-mddsp.enel.ucalgary.ca/People/adilger/
http://sourceforge.net/projects/ext2resize/
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: your mail
2002-08-30 18:43 Bloch, Jack
2002-08-30 18:55 ` your mail Matthew Dharm
2002-08-30 19:22 ` Andreas Dilger
@ 2002-08-31 0:12 ` David Woodhouse
2 siblings, 0 replies; 4+ messages in thread
From: David Woodhouse @ 2002-08-31 0:12 UTC (permalink / raw)
To: Andreas Dilger; +Cc: Bloch, Jack, linux-kernel
adilger@clusterfs.com said:
> I would instead suggest using a filesystem like JFFS2 for flash
> devices. This is journaled like ext3, but it also has the benefit of
> doing wear levelling on the device, which otherwise will probably wear
> out the superblock part of the flash rather quickly.
He said he's using CompactFlash. CompactFlash is not flash, as far as we're
concerned: it is an IDE drive. You may think it has flash inside it; we
couldn't possibly comment.
In fact, it generally has a kind of pseudo-filesystem internally which it
uses to emulate a block device with 512-byte sectors. It may do its own
wear-levelling; the manufacturers are often quite cagey about whether it
actually does or not. Draw your own conclusions about that if you will.
It's quite common to find that this internal pseudo-filesystem _itself_ gets
screwed on power failures. This tends to manifest itself as unrecoverable
I/O errors.
There is no fundamental reason why every CF card should have these
problems, in the same way as there is no fundamental reason why all PC
BIOSes should be crap. But the same expectations apply.
If you want to pass power-fail testing, I would recommend you switch to
using real flash. JFFS2 on real flash has survived days of stress testing
whilst being power cycled randomly every ~5 minutes. The same tests were
observed to destroy CF cards¹.
CF is bog-roll technology. It's disposable storage designed for temporary
use in stuff like cameras -- not for real computing. Think of it like a
floppy disc and you won't go far wrong.
--
dwmw2
¹ http://www.embeddedlinuxworks.com/articles/jffs_guide.html²
² Constant reboots no longer screw the wear levelling, as reported there.
^ permalink raw reply [flat|nested] 4+ messages in thread