From: Philipp Rumpf <prumpf@uzix.org>
To: David Woodhouse <dwmw2@infradead.org>
Cc: Alexander Larsson <alex@cendio.se>,
Markus Thiesmeyer <mthi@gmx.de>,
mtd@infradead.org, jffs-dev@axis.com, bmatthews@redhat.com
Subject: Re: Is JFFS a full featured filesystem?
Date: Wed, 2 Aug 2000 09:58:48 -0700 [thread overview]
Message-ID: <20000802095848.B20345@fruits.uzix.org> (raw)
In-Reply-To: <24735.965226004@cygnus.co.uk>
On Wed, Aug 02, 2000 at 03:20:04PM +0100, David Woodhouse wrote:
> alex@cendio.se said:
> > Exactly how did you plan to work out the dirty ranges? Compare with
> > on-flash contents?
>
> Apparently it's easy when using generic_file_write, because prepare_write
> will give you the exact range.
Both prepare_write and commit_write, so we have full control over what
happens. The arguments to {prepare,commit}_write are offsets within the
actual page (so <= PAGE_SIZE), but page->index holds the higher bits of
the logical offset.
> When doing writable mmap() we have to do something cleverer - basically yes,
> comparing with the on-flash contents. We can either do that by going and
> reading the flash nodes again on writepage(), or we can keep a copy of the
> clean page in RAM before it's dirtied.
Or we can just make writable mmap()s fail - applications should handle that
case, and it seems rather easy to fuck up and corrupt an fs by not handling
it correctly.
> To start with, I'm inclined just to accept the hit of the 4Kb writes, and
> let the GC combine nodes later as necessary. Comparing with old contents
> can come later. This is only going to be a problem with writable mmap(),
> which isn't supported at the moment _anyway_. The normal write() case is
I don't see where a writable mmap() fails in 2.2 - in 2.4 it's obvious.
Philipp
To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org
next prev parent reply other threads:[~2000-08-02 16:58 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-08-01 16:15 Is JFFS a full featured filesystem? Markus Thiesmeyer
2000-08-01 18:08 ` Philipp Rumpf
2000-08-02 11:13 ` Alexander Larsson
2000-08-02 12:11 ` David Woodhouse
2000-08-02 12:24 ` David Woodhouse
2000-08-02 13:45 ` Alexander Larsson
2000-08-02 13:52 ` David Woodhouse
2000-08-02 14:20 ` David Woodhouse
2000-08-02 15:33 ` Alexander Larsson
2000-08-02 16:58 ` Philipp Rumpf [this message]
2000-08-02 14:13 ` Alexander Larsson
2000-08-02 16:50 ` Philipp Rumpf
2000-08-02 18:06 ` Alexander Larsson
2000-08-02 19:36 ` Philipp Rumpf
2000-08-02 19:57 ` Alexander Larsson
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=20000802095848.B20345@fruits.uzix.org \
--to=prumpf@uzix.org \
--cc=alex@cendio.se \
--cc=bmatthews@redhat.com \
--cc=dwmw2@infradead.org \
--cc=jffs-dev@axis.com \
--cc=mtd@infradead.org \
--cc=mthi@gmx.de \
/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.