lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Wed, 2 Apr 2008 08:25:43 +0200 From: Willy Tarreau <w@....eu> To: Artem Bityutskiy <dedekind@...dex.ru> Cc: "H. Peter Anvin" <hpa@...or.com>, Andi Kleen <andi@...stfloor.org>, Tomasz Chmielewski <mangoo@...g.org>, LKML <linux-kernel@...r.kernel.org>, penberg@...helsinki.fi, Jörn Engel <joern@...fs.org>, ext-adrian.hunter@...ia.com, jwboyer@...il.com Subject: Re: UBIFS vs Logfs (was [RFC PATCH] UBIFS - new flash file system) On Wed, Apr 02, 2008 at 07:47:25AM +0300, Artem Bityutskiy wrote: > 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. > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists