From: Mark Hatle <fray@mvista.com>
To: Rod Boyce <rod_boyce@stratexnet.com>
Cc: Alex Zeffertt <ajz@cambridgebroadband.com>,
linuxppc-embedded@lists.linuxppc.org
Subject: Re: Stable File System for embedded product
Date: Mon, 19 Jan 2004 15:00:10 -0600 [thread overview]
Message-ID: <400C455A.3080603@mvista.com> (raw)
In-Reply-To: <A3240F62EF3C2749B1A25D3BC9548F410309BE@ExchWENZ02.wenz.global.vpn>
Just from the FHS perspective (the file system standard for Linux)
everything on linux can (and should be) read-only mounted, with the
following exceptions:
/etc/mtab -- It can be a symlink to /proc/mounts (or a link to a
writable location)
/tmp -- mount as a tmpfs (or link to /var/tmp)
/var -- mount again as a tmpfs, or a read-write storage
Of course each distribution varies and applications, distributions, etc
have bugs when it comes to FHS compliance.. but this should be the
end-goal for all systems to be standards based.
(For my own systems, usually I have /etc on a read-write capable disk..
but mount read-only.. /etc/mtab is a symlink to /proc/mounts, /tmp is a
symlink to /var/tmp. /var/tmp is tmpfs.. the rest of var is either
tmpfs or a read-write disk depending on the application.)
--Mark
Rod Boyce wrote:
> I would much more strongly suggest not mounting this partition
> read-write as this is most likely what is corrupting the partition also
> try noatime as well. /etc is required for boot up so I would suggest
> changing the way you use /etc. We have soft links to another location
> on another file system and keep /etc combined with the root file system.
> Upwards of 10K power cycles can't be wrong.
>
>
> Rod
>
>
>>-----Original Message-----
>>From: Alex Zeffertt [mailto:ajz@cambridgebroadband.com]
>>Sent: Monday, 19 January 2004 11:04 p.m.
>>To: S. Hebbar
>>Cc: linuxppc-embedded@lists.linuxppc.org
>>Subject: Re: Stable File System for embedded product
>>
>>
>>Are you using a flash device (i.e. /dev/mtdblockN) for /etc? If so,
>>then I would recommend JFFS for this partition. JFFS2 is (supposedly)
>>more reliable, but we have found that you can't fit it on a flash
>>partition of only 4 flash sectors since it needs more than that for
>>scratch.
>>
>>If it's not flash then maybe you should consider ext3 - a journalling
>>extension to ext2.
>>
>>Alex
>>
>>On Mon, 2004-01-19 at 06:23, S. Hebbar wrote:
>>
>>>Hello,
>>>
>>>I am trying to find which file system is the best for
>>>/etc partition on an embedded linux platform.
>>>
>>>I am using the following file systems for linux & rootfs:-
>>>Linux: CramFS (linux 2.4.20 denx) (read-only)
>>>RootFS: CramFS (read-only)
>>>
>>>At the moment, I am using ext2 partition for /etc (read-write)
>>>But, 1 out of 4 power-cycles of the board corrupts the
>>>/etc partition.
>>>
>>>Any information related to the above topic is
>>>grately appreciated.
>>>
>>>Regards,
>>>S. Hebbar.
>>>
>>>
>>
>>
>
>
>
>
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
next prev parent reply other threads:[~2004-01-19 21:00 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-01-19 18:47 Stable File System for embedded product Rod Boyce
2004-01-19 21:00 ` Mark Hatle [this message]
-- strict thread matches above, loose matches on Subject: below --
2004-01-19 6:23 S. Hebbar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=400C455A.3080603@mvista.com \
--to=fray@mvista.com \
--cc=ajz@cambridgebroadband.com \
--cc=linuxppc-embedded@lists.linuxppc.org \
--cc=rod_boyce@stratexnet.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.