From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from <gentoo-embedded+bounces-3417-garchives=archives.gentoo.org@lists.gentoo.org>) id 1Nwup4-0001G2-Vs for garchives@archives.gentoo.org; Wed, 31 Mar 2010 10:06:55 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 8CEC1E0EB5 for <garchives@archives.gentoo.org>; Wed, 31 Mar 2010 10:06:54 +0000 (UTC) Received: from smtprelay-h11.telenor.se (smtprelay-h11.telenor.se [62.127.194.4]) by pigeon.gentoo.org (Postfix) with ESMTP id 105ECE0BC8 for <gentoo-embedded@lists.gentoo.org>; Wed, 31 Mar 2010 09:26:56 +0000 (UTC) Received: from ipb1.telenor.se (ipb1.telenor.se [195.54.127.164]) by smtprelay-h11.telenor.se (Postfix) with ESMTP id A600CE9065 for <gentoo-embedded@lists.gentoo.org>; Wed, 31 Mar 2010 11:26:53 +0200 (CEST) X-SENDER-IP: [213.114.144.197] X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj5BAMuxskvVcpDFPGdsb2JhbACDEoRSh1yLbwwBAQEBNS2ubJBWgSuCa2oE X-IronPort-AV: E=Sophos;i="4.51,340,1267398000"; d="scan'208";a="57855378" Received: from c-c59072d5.029-89-73746f3.cust.bredbandsbolaget.se (HELO mali) ([213.114.144.197]) by ipb1.telenor.se with ESMTP; 31 Mar 2010 11:26:51 +0200 Received: from sth491dt.servo.net (localhost [127.0.0.1]) by mali (Postfix) with ESMTP id 28ED01137B0 for <gentoo-embedded@lists.gentoo.org>; Wed, 31 Mar 2010 11:26:50 +0200 (CEST) Date: Wed, 31 Mar 2010 11:26:49 +0200 From: =?UTF-8?B?TmVib2rFoWEgxIZvc2nEhw==?= <nebojsa@asnn.org> To: gentoo-embedded@lists.gentoo.org Subject: Re: [gentoo-embedded] file system question Message-ID: <20100331112649.7365bb19@sth491dt.servo.net> In-Reply-To: <20100329184215.539920eb@osage.osagesoftware.com> References: <20100329184215.539920eb@osage.osagesoftware.com> X-Mailer: Claws Mail 3.7.5 (GTK+ 2.18.9; i686-pc-linux-gnu) Precedence: bulk List-Post: <mailto:gentoo-embedded@lists.gentoo.org> List-Help: <mailto:gentoo-embedded+help@lists.gentoo.org> List-Unsubscribe: <mailto:gentoo-embedded+unsubscribe@lists.gentoo.org> List-Subscribe: <mailto:gentoo-embedded+subscribe@lists.gentoo.org> List-Id: Gentoo Linux mail <gentoo-embedded.gentoo.org> X-BeenThere: gentoo-embedded@lists.gentoo.org Reply-to: gentoo-embedded@lists.gentoo.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: 8166f305-c1eb-4f05-9c76-e37d98d21baa X-Archives-Hash: c2df51480b1739839e3199a4c0cd117a > G'day, >=20 > I'm porting the software for an embedded medical device from DOS to > Linux and am wondering which file systems are appropriate and which are > not. The device's mass storage is a Disk-on-Module solid state flash > drive. Data is presently written at approx 100 bytes every 30 seconds > but that might change to 100 bytes every second. The device has a > watchdog (recently activated) and during today's session it was > triggered and wiped out my file system. >=20 > Anybody have recommendations on which file system to use and the > appropriate settings? >=20 > Anybody have suggested readings so I can educate myself? >=20 > Thank you. >=20 > David >=20 After having problems with EMC and usb storage, I finally fixed the problem with following solution: - data storage, in my case usb stick, has at least 2 partitions - second partition is without file system. It is divided in a number of slots, each large enough to store all of my data - all work is performed on data stored on ram disk - periodically (triggered by time and/or data change), I compress ram disk and dump it in a next slot on unformatted partition I have a small battery, which I use to do one final dump at shutdown time. On startup, I go through all of the slots in second partition, searching for latest uncorrupt data, and use this to populate ram disk. If you can live with some data loss, you don't even need battery backup. No matter wear leveling implementation on your storage, this solution works optimally. It works even on your directly accessible flash storage. Since there is no real file system on partition, there is no need for it's recovery - besides searching for latest and greatest set of data on startup And it is implemented as a ash script, using tar and gzip, so your data is actually better verified than on normal file system (the usual one do not actually checksum data. I don't consider jffs2 to be "the usual filesystem":) Neboj=C5=A1a