* Stable File System for embedded product
@ 2004-01-19 6:23 S. Hebbar
0 siblings, 0 replies; 3+ messages in thread
From: S. Hebbar @ 2004-01-19 6:23 UTC (permalink / raw)
To: linuxppc-embedded
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/
^ permalink raw reply [flat|nested] 3+ messages in thread
* RE: Stable File System for embedded product
@ 2004-01-19 18:47 Rod Boyce
2004-01-19 21:00 ` Mark Hatle
0 siblings, 1 reply; 3+ messages in thread
From: Rod Boyce @ 2004-01-19 18:47 UTC (permalink / raw)
To: Alex Zeffertt; +Cc: linuxppc-embedded
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/
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Stable File System for embedded product
2004-01-19 18:47 Stable File System for embedded product Rod Boyce
@ 2004-01-19 21:00 ` Mark Hatle
0 siblings, 0 replies; 3+ messages in thread
From: Mark Hatle @ 2004-01-19 21:00 UTC (permalink / raw)
To: Rod Boyce; +Cc: Alex Zeffertt, linuxppc-embedded
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/
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2004-01-19 21:00 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-01-19 18:47 Stable File System for embedded product Rod Boyce
2004-01-19 21:00 ` Mark Hatle
-- strict thread matches above, loose matches on Subject: below --
2004-01-19 6:23 S. Hebbar
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.