From: arnd@arndb.de
To: linux-fsdevel@vger.kernel.org
Cc: linux-kernel@vger.kernel.org, hch@lst.de
Subject: [RFC 0/7] [RFC] cramfs: fake write support
Date: Sat, 31 May 2008 17:37:58 +0200 [thread overview]
Message-ID: <200805311737.58991.arnd@arndb.de> (raw)
Inspired by a discussion with Christoph Hellwig, I tried to
recreate a patch that he did a few years ago to add support
for writing to a mounted cramfs file system. It still has
known problems (and likely unknown ones), but should be
good enough for practical use. I've been able to boot
a full Ubuntu installation from a cramfs image and work with
it normally.
The intention is to use it for instance on read-only root
file systems like CD-ROM, or on compressed initrd images.
In either case, no data is written back to the medium, but
remains in the page/inode/dentry cache, like ramfs does.
Many existing systems currently use unionfs or aufs for this
purpose, by overlaying a tmpfs over a read-only file
system like cramfs, squashfs or iso9660. IMHO, it would
be a much nicer solution to not require unionfs for a simple
case like this, but rather have support for it in the file
system. If people find this useful, we can do the same in
other read-only file system.
Writing to existing files is broken in at least two corner
cases, and I'm still looking for a solution here:
When you truncate an on-disk to make it larger, reading
beyond the old end of the file will make cramfs try to
read from disk instead of filling with zeroes. I'm not sure
if this can be solved without adding additional members to
the inode structure (using a private inode cache) to remember
the end of the on-disk file.
Deleting a preexisting file currently does not free the inode
and page cache for that file, which I assume is easy to fix.
Also, the i_nlink field of directories is always 1, and
has always been on cramfs. Getting the count right should
simplify the code a bit and make it more correct according
to posix, but will cost a bit of performance on 'stat'.
The patch series also lives on
git://git.kernel.org:/pub/scm/linux/kernel/git/arnd/playground.git cramfs
Comments?
Arnd <><
next reply other threads:[~2008-05-31 15:39 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-05-31 15:37 arnd [this message]
2008-05-31 18:56 ` [RFC 0/7] [RFC] cramfs: fake write support David Newall
2008-05-31 20:40 ` Arnd Bergmann
2008-06-01 3:54 ` Phillip Lougher
2008-06-01 8:52 ` Arnd Bergmann
2008-06-01 12:28 ` Jamie Lokier
2008-06-01 21:49 ` Arnd Bergmann
2008-06-02 2:48 ` hooanon05
2008-06-02 3:25 ` Erez Zadok
2008-06-02 7:51 ` Arnd Bergmann
2008-06-02 18:13 ` Erez Zadok
2008-06-03 2:02 ` Phillip Lougher
2008-06-02 3:51 ` Erez Zadok
2008-06-02 11:07 ` Jamie Lokier
2008-06-02 4:37 ` Erez Zadok
2008-06-02 6:07 ` Bharata B Rao
2008-06-02 7:17 ` Jan Engelhardt
2008-06-02 7:12 ` Arnd Bergmann
2008-06-02 10:36 ` hooanon05
2008-06-02 11:15 ` Arnd Bergmann
2008-06-02 12:56 ` hooanon05
2008-06-02 14:13 ` Arnd Bergmann
2008-06-02 14:33 ` hooanon05
2008-06-02 15:01 ` Arnd Bergmann
2008-06-03 11:04 ` hooanon05
2008-06-02 14:54 ` Evgeniy Polyakov
2008-06-02 17:42 ` Arnd Bergmann
2008-06-02 15:35 ` Erez Zadok
2008-06-01 6:02 ` David Newall
2008-06-01 9:11 ` Jan Engelhardt
2008-06-01 16:25 ` Jörn Engel
2008-06-01 3:19 ` Phillip Lougher
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=200805311737.58991.arnd@arndb.de \
--to=arnd@arndb.de \
--cc=hch@lst.de \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/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