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 ) id 1NwmUs-0000Ei-1p for garchives@archives.gentoo.org; Wed, 31 Mar 2010 01:13:30 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id A9682E0BDC for ; Wed, 31 Mar 2010 01:13:29 +0000 (UTC) Received: from mail.osagesoftware.com (osagesoftware.com [216.144.204.42]) by pigeon.gentoo.org (Postfix) with ESMTP id C7E58E0E25 for ; Wed, 31 Mar 2010 00:44:35 +0000 (UTC) Received: from osage.osagesoftware.com (osage.osagesoftware.com [192.168.1.10]) by mail.osagesoftware.com (Postfix) with ESMTP id A0C727BC88; Tue, 30 Mar 2010 20:44:34 -0400 (EDT) Date: Tue, 30 Mar 2010 20:44:34 -0400 From: David Relson To: gentoo-embedded@lists.gentoo.org Cc: karl@hiramoto.org Subject: Re: [gentoo-embedded] file system question Message-ID: <20100330204434.34c9dfe3@osage.osagesoftware.com> In-Reply-To: <4BB1FC9B.9070804@hiramoto.org> References: <20100329184215.539920eb@osage.osagesoftware.com> <4BB1FC9B.9070804@hiramoto.org> Organization: Osage Software Systems, Inc. X-Mailer: Claws Mail 3.7.5 (GTK+ 2.18.7; x86_64-pc-linux-gnu) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-embedded@lists.gentoo.org Reply-to: gentoo-embedded@lists.gentoo.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Archives-Salt: bc85085f-afb0-4f6c-bb0b-fa45d06f681a X-Archives-Hash: aec91857cc777f93ab06b41b10f04cc1 Hello, All! The many suggestions have been very helpful. This afternoon, 'sync' was added to fstab. No problems have been seen since. While not conclusive, the indication is good and we're helpful. The device in question is a medical device that continuously takes readings, graphs them, and every 30 seconds appends a 34 byte data record to each of two files. It's not exactly disk intensive :-> FWIW, often the files hit by the "Stale NFS file handle" problem are symlinks in /usr/lib. Since _nobody_ writes that directory it's odd that the problem often shows up there. That's not the only place, but seems to be the most common one. The suggestion of separate partitions for program and data is one I like and shall implement. Thanks for the idea! The power cord isn't a problem -- there's an onboard battery. However the power button can be pressed at any time. 'Tis something that we'll live with. Adding fsync() calls, in addition to 'sync' mounting, should help. Ciao! David On Tue, 30 Mar 2010 15:28:59 +0200 Karl Hiramoto wrote: > On 03/30/2010 12:42 AM, David Relson wrote: > > G'day, > > > > 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. > > > It sounds like some kind of data logging application. If this is > the case what i would do is. > > 1. Mount read only a partition that contains the main system, to > ensure you can always boot and to avoid damage to the systems file > > 2. Mount read/write the partition that data gets written to. On boot > you can detect errors in this partition and reformat it if is totally > hosed. > > 3. In your application call fsync() on the file and perhaps the > directory after the writes to make sure the data gets to the flash. > If you are in fact logging, rotate your logs files so after they are > X size write to a new file. Files that are most likely to be > damaged are ones that are opened and being written to the moment the > power cord gets yanked. > > As Manual said, using the 'sync' option may help. Also see "man > mount" and /usr/src/linux/Documentation/filesystems/ext3.txt > > Other options the improve reliability are data=journal and barrier=1 > > > I've used ext3 and riserfs on CompactFlash but neither seems to be > 100% error proof. I've wanted to try NILFS2 but haven't done it yet. > > -- > Karl > > >