On Wed, Apr 02, 2008 at 07:47:25AM +0300, Artem Bityutskiy wrote:
quoted text
> Willy Tarreau wrote:
> >>Well, even auto-levelling storage should benefit from a filesystem which 
> >>minimizes the total number of flash sectors churned, which means doing 
> >>as few writes as possible and to large, contiguous sections.
> >
> >Exactly. At exosec, we ship one appliance which writes statistics to a
> >partition on a compactflash every 5 minutes. We preferred to go with JFFS2
> >exactly because of this reason. We never had any problem proceeding this 
> >way.
> >I'm not sure if it would have been the same with ext2 though.
> >
> 
> Yes, as I agreed in a previous mail this may make sense in some cases.
> 
> But in general it is not a good approach. Basically, it is wastage of 
> resources.
> Indeed, first the firmware on MMC/SD/etc makes efforts to make flash look
> like a block device. It gives you in-place updates,

One of the problem is that unless you crash-test your flash cards, you will
never know if their wear-leveling algorithm is fine or not. And I suspect
that nowadays, due to very large consumer demand, flash cards price drop
at the cost of reliability. I think that most of those not flagged
"industrial-grade" do absolutely zero wear-leveling, because they are sold
to people using them in digital cameras, and they will never kill their
device with such a usage.

quoted text
> but by cost of performance
> and reliability. Then you just drop this nice property, and use JFFS2, which
> assumes it has only out-of-place updates. But if this solves the task you 
> have

I'm certainly not the only one with this requirement. A lot of embedded
motherboards come with IDE compactflash connectors. This is very convenient,
but if you need to keep informations between reboots, you have to write to
the device anyway. If you need to do that very often, either you pray for
the device to be very reliable, or you take all the chances on your side
by adding your own wear-leveling "just in case".

Cheers,
Willy

--
unsubscribe notice
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/