[Fwd: [Fwd: power down]]

[Fwd: [Fwd: power down]]

[Vipin Malik]

Bob Canup wrote:
> 
> Vipin Malik wrote:
> 
> > Bob Canup wrote:
> > >
> 
> I don't think that you understand what we're trying to tell you. There is a
> difference in philosophy.
> 
> If you are running a flash as a normal read - write imitation of a disk there
> are severe time limitations as to how long the flash is going to work because
> of the limit on write cycles which flash technology has. As has been pointed
> out in an earlier post - one write a second will ruin a flash chip in a few
> weeks - which is not a very long for an embedded system to work.

One dosen't have to write to the flash every second, even if logs are
being generated that fast. You can accumulate writes in RAM (even backud
up RAM), and then archive them to FLASH every 5 minutes etc.

This is with RAW flash that does suffer from limited writes. If you have
some level of wear leveling then the # of writes one can do go up by an
order of magnitude.



> 
> Because of this limitation most of the people in this group who do design
> with flash use it in a Write Rarely Read Mostly manner. The only time the
> flash is written to is when there is a firmware upgrade. This is also the
> manner in which flash chips are used on conventional PC motherboards - if you
> lose power during a firmware upgrade - you are in trouble - nor do I see any
> practical method of handling that problem.

PC mother boards are NOT embedded systems. I refuse to accept any
limitation in the PC world to be applicable to the embedded world.


> 
> If you are trying to use the flash in a data - logging application where the
> file system has to be read - write to store data you are very quickly going
> to run into the write cycle limitations of the technology. I don't think that
> flash is the correct technology to use in such an application.


> 
> We use our DOC2000 in read only mode - with things like /var in volatile ram
> disk - we have found this to be a satisfactory way of doing things.

Some applications are ok this way. not all. If we are implementing a
solution general enough for all embedded systems, then this is a very
severe limitation.

> 
> Now - as to the issue of a POWER GOOD signal. The inverse of a POWER GOOD
> signal is *POWER BAD. The reason for sending this signal to a chip is to tell
> it that it won't function properly if it attempts to perform its operation.
> But if the power is bad the chip is not working properly so it can't respond
> properly to the *POWER BAD signal. This is the equivalent of saying to a dead
> man "You're dead". That is true - but it does little good to tell him that.
> 
> That is the reason that there are no POWER GOOD input pins on anybody's
> chips. In addition the analog detectors which generate the *POWER BAD signal
> do not respond in nanoseconds - that is the reason for my analogy to the SCR
> crowbar. By the time that the analog detectors respond you have been
> operating the chips out of spec for a long time by digital standards.

well actually, there is a "power good" pin on *ALL* microprocessors.
It's called RESET!
The system asserts this reset pin, keeping the micro from doing crazy
things till power stabilizes in the system and comes within the spec of
the micro. similarly on the downside, this reset is again asserted as
soon as power goes out of spec. The operation of reset functionality is
guranteed by the micro manufacturer for a range WAY beyond normal
operating voltage range of the chip.

As far as my experience tells me. This works!

> 
> Now because of the Yin and Yang nature of reality there can be some use to a
> properly designed power fail detection circuit - but the way they are mostly
> used is as a placebo.

I dont't agree with this. Lets just leave it at that :)

> 
> To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org


To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

[Fwd: [Fwd: power down]]

[Vipin Malik]

David Woodhouse wrote:
> 
> vmalik@danielind.com said:
> >  <desperate plea> Come on guys (and gals). Am I championing a lost
> > cause here? Have we given up on power down reliability of nonvolatile
> > data in embedded systems under Linux?
> 
> Power down reliability of such data is an absolute must.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
THANK YOU, THANK YOU, THANK YOU!!!!

> I expect embedded
> systems using NFTL and ext3 to be absolutely reliable even if the plug is
> pulled half-way through a write.
> 
> This means we end up with two separate journalling / logging mechanisms - one
> at the block device level (ext3) and one at the flash media level (NFTL). As I
> said - ideally, we ditch that in the end and have a journalling/log-structured
> filesystem directly on the flash media.
> 
> > Is anyone interested in this!? Lurkers please respond. How many people
> > read this list anyway? </desperate plea>
> 
> infradead /var/lib/majordomo/lists $ wc -l mtd
>      64 mtd

Thanks. I guess that means that 64 people receive this list.

> 
> --
> dwmw2


To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

[Fwd: [Fwd: Power Down]]

[Vipin Malik]

David Woodhouse wrote:
> 
> vmalik@danielind.com said:
> >  Is ext3 already available in beta form? Is it included in the latest
> > 2.3.x kernels?
> 
> yes, no.
> 
> ftp.uk.linux.org:/pub/linux/sct/fs/jfs/ext3-0.0.2c.tar.gz
Thanks for the link. I checked ext3 out. what I found...
1. It is still in pre form. Not too bad, but probably at least 6 months
(or more) away from being production quality. Not too big a deal for
projects about 1+yr out.

2. This is the big one: It needs 1024 blocks for the journal file. At
1k/block, this translates into 1 meg journal file. This could be a
*significant* overhead for small file systems (<10M).

I'm going to download the pre and play with it for a while to get a
first hand impression of it. But the 1 meg journal file overhead is too
big for medium size embedded systems.

Unfortunately journalling still dosen't solve the problem (that I say
first hand) of one entire (512byte) flash block "go bad". The only
solution I found to recover this block resulted in the erasure of the
ENTIRE block. Now this was at the lowest level (below the file system).
I don't know how even a journaled file system would recover stuff
(inodes etc.) disappearing from under its feet. Dosen't give me a warm
and fuzzy about it.

> 
> > What is the overhead of Journalling? (CPU AND flash space). Of course
> > if that solves the problem, then that is the most important thing (for
> > me at least).
> 
> I don't know - I haven't looked into it much yet.
> 
> vmalik@danielind.com said:
> > One dosen't have to write to the flash every second, even if logs are
> > being generated that fast. You can accumulate writes in RAM (even
> > backud up RAM), and then archive them to FLASH every 5 minutes etc.
> 
> vmalik@danielind.com said:
> >  When I write a log, I want it written and saved. I guess one could do
> > sync() etc. every time but not very elegant.
> 
> Err... which do you want? You can't have both.

LOL :) Actually what I meant was that in the write to RAM and then in
batch mode save to FLASH situation, I meant that when I want to store
the "batch" of logs accumulated in RAM to FLASH I want the thing "done!"
rather than "hang around" in VFS buffers etc.

> 
> --
> dwmw2


To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org