From: Wolfgang Denk <wd@denx.de>
To: "Song Sam" <samlinuxppc@yahoo.com.cn>
Cc: linuxppc-embedded@lists.linuxppc.org
Subject: Re: Cramfs Limitations
Date: Fri, 27 Aug 2004 09:38:33 +0200 [thread overview]
Message-ID: <20040827073838.E2DD9C109F@atlas.denx.de> (raw)
In-Reply-To: Your message of "Fri, 27 Aug 2004 09:35:50 +0800." <20040827013550.73877.qmail@web15605.mail.cnb.yahoo.com>
In message <20040827013550.73877.qmail@web15605.mail.cnb.yahoo.com> you wrote:
>
> > Are you really surprised that opening a file for
> > writing fails on a read-only filesystem???
>
> So only for this reason, I cannot choose Cramfs for my
> application deployment??? Then I have nearly no other
Why not? Of course you can. You just cannot write to it.
> choice but use JFFS2 for deployment, which performance
> couldn't compare with RAMDISK.It's a pity that RAMDISK
> cannot update some info permanently. EXT2 seems not a
You can use any filesystem, including one on a RAMDISK.
If the root filesystem happens to be read-only, you just need to
provide a writable filesystem for those things that need to get
written. In case of data that may get lost at reboot you can use
tmpfs, and for persistent storage you can use JFFS2.
If you are concerned about updating individual files in your
read-only filesystem (instead of updating the whole image (*)) you
can use an overlay filesystem. For example, you can use "mini_fo"
which was specifically tailored for such purposes; please see
http://atlas.denx.de/denx/e/news.php#MINI_FO
(*) Updating the whole image is not a bad idea - this way you can
guarantee that all files int he image are really compatible with
each other; keeping the system in a consisten state is much more
difficult when individual files can get replaced at random.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd@denx.de
"UNIX was not designed to stop you from doing stupid things, because
that would also stop you from doing clever things." - Doug Gwyn
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
next prev parent reply other threads:[~2004-08-27 7:38 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-08-12 14:29 MPC82xx enet on SCC3 Oliver Fuchs
2004-08-12 16:55 ` Dan Malek
2004-08-16 14:00 ` Oliver Fuchs
2004-08-16 16:21 ` Wolfgang Denk
2004-08-16 17:40 ` Ralph Siemsen
2004-08-17 9:49 ` Oliver Fuchs
2004-08-26 10:08 ` Cramfs Limitations Song Sam
2004-08-26 15:12 ` Wolfgang Denk
2004-08-27 1:35 ` Song Sam
2004-08-27 7:38 ` Wolfgang Denk [this message]
2004-08-27 8:33 ` Song Sam
2004-08-26 10:10 ` Does ext2 based on MTD acceptable for Embedded Development? Song Sam
2004-08-27 7:08 ` Oliver Fuchs
2004-08-27 7:39 ` Wolfgang Denk
2004-08-27 10:05 ` Oliver Fuchs
2004-08-27 14:24 ` Wolfgang Denk
2004-08-16 18:18 ` MPC82xx enet on SCC3 Dan Malek
2004-08-17 9:49 ` Oliver Fuchs
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=20040827073838.E2DD9C109F@atlas.denx.de \
--to=wd@denx.de \
--cc=linuxppc-embedded@lists.linuxppc.org \
--cc=samlinuxppc@yahoo.com.cn \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).