Re: Getting big flash onto motherboards. Will CF work? what will

Re: Getting big flash onto motherboards. Will CF work? what will

[Chris Wilson]

Hi All,

This is my first post, please excuse me if I do something bad...

> >there are DOC devices that plug into IDE
> 
> These are called DiskonModule  (as opposed to diskonchip).  
> 
> They come in both 40 and 44 pin connections.  They arent very big, they
> look like a terminator.  Most are flat, like a hard drive (but much shorter
> & smaller), some have an L-shape.

I would guess that these are IDE-compatible then? So I guess I would have 
to use the mtdblock driver to drive it? Does it have internal wear 
levelling like CF?

I know CompactFlash isn't on topic really but I hope someone has used it 
and can give me some advice. We have been using CF in our firewalls for 
"high reliability" - but unfortunately the results have not been 
impressive.

After some period of operation as a root filesystem (with reads and
writes), between a week and three months, the CF cards seem to "lock up".  
Nothing can be read from them (or written, I think) and /sbin/badblocks,
if it runs at all, reports every sector as bad. Rebooting the machine
"cures" the problem.

Has anyone seen this behaviour, or had any clues about how or why it might 
happen? We have had the same effect with several different brands of CF, 
including SanDisk. Does this kind of thing happen to DoC and/or DoM?

I know writing lots to CF is a bad idea, we're working on fixing it, but 
we have no evidence that just reading from a CF isn't going to make it 
lock up eventually... RAID would be more reliable!

Cheers, Chris.
-- 
   ___ __     _
 / __// / ,__(_)_  | Chris Wilson -- UNIX Firewall Lead Developer |
/ (_ / ,\/ _/ /_ \ | NetServers.co.uk http://www.netservers.co.uk |
\ _//_/_/_//_/___/ | 21 Signet Court, Cambridge, UK. 01223 576516 |

Re: Getting big flash onto motherboards. Will CF work? what will

[David Woodhouse]

chris@netservers.co.uk said:
>  I would guess that these are IDE-compatible then? So I guess I would
> have  to use the mtdblock driver to drive it? 

No. The mtdblock driver is a vary simplistic 'translation layer' that 
doesn't actually do any wear levelling or translation, just lets you use a 
real flash device as if it were a block device.

If the hardware in question looks like IDE, you use the IDE drivers. 

> Does it have internal wear  levelling like CF?

It might. You cannot tell, just like with CF.


> Has anyone seen this behaviour, or had any clues about how or why it
> might  happen? We have had the same effect with several different
> brands of CF,  including SanDisk. Does this kind of thing happen to
> DoC and/or DoM?

I have no knowledge of the DiskOnModule. It's just like CF in all respects
other than the physical size, isn't it? So there's no real reason to believe
that it must have different reliability characteristics. But there's no real
reason for _everyone_ who makes CF to have implemented it so unreliably in
the first place -- so maybe M-Systems have managed to do it properly -- they
generally do seem to have sufficient clue. You'd have to test it.

The DiskOnChip is a different matter. That allows the system to deal with 
real flash, so if there are problems you can fix them. Although in 
practice, nobody _does_ seem to be dealing with the problems which 
occasionally crop up with the DiskOnChip drivers. I still keep trying to 
get our salespeople to find a customer who wants to pay for me to spend 
some real time on them, but it hasn't happened yet :)

--
dwmw2

Re: Getting big flash onto motherboards. Will CF work? what will

[Chris Wilson]

Hi David,

> chris@netservers.co.uk said:
> >  I would guess that these are IDE-compatible then? So I guess I would
> > have  to use the mtdblock driver to drive it? 
> 
> No. The mtdblock driver is a vary simplistic 'translation layer' that 
> doesn't actually do any wear levelling or translation, just lets you use a 
> real flash device as if it were a block device.

Sorry, I meant mtdblkdev. Silly me =)

> that it must have different reliability characteristics. But there's no real
> reason for _everyone_ who makes CF to have implemented it so unreliably in
> the first place -- so maybe M-Systems have managed to do it properly -- they
> generally do seem to have sufficient clue. You'd have to test it.

Thanks for your answer, even though it's not encouraging news. I guess we 
will have to thrash some CFs to death to find out what's going wrong =( 
It's a shame because they are so expensive.

> The DiskOnChip is a different matter. That allows the system to deal with 
> real flash, so if there are problems you can fix them. Although in 
> practice, nobody _does_ seem to be dealing with the problems which 
> occasionally crop up with the DiskOnChip drivers. I still keep trying to 
> get our salespeople to find a customer who wants to pay for me to spend 
> some real time on them, but it hasn't happened yet :)

We'll consider it if I can persuade my boss that we shouldn't be using CF 
=)

Incidentally, do you or anyone know why there is such a big price 
different between CF, DoM and DoC for the same capacity?

Cheers, Chris.
-- 
   ___ __     _
 / __// / ,__(_)_  | Chris Wilson -- UNIX Firewall Lead Developer |
/ (_ / ,\/ _/ /_ \ | NetServers.co.uk http://www.netservers.co.uk |
\ _//_/_/_//_/___/ | 21 Signet Court, Cambridge, UK. 01223 576516 |