All of lore.kernel.org
 help / color / mirror / Atom feed
From: Philipp Rumpf <prumpf@uzix.org>
To: Alexander Larsson <alex@cendio.se>
Cc: Markus Thiesmeyer <mthi@gmx.de>,
	David Woodhouse <dwmw2@infradead.org>,
	mtd@infradead.org
Subject: Re: Is JFFS a full featured filesystem?
Date: Wed, 2 Aug 2000 12:36:23 -0700	[thread overview]
Message-ID: <20000802123623.C20345@fruits.uzix.org> (raw)
In-Reply-To: <Pine.LNX.3.96.1000802185749.2678B-100000@biffen.cendio.se>

On Wed, Aug 02, 2000 at 08:06:42PM +0200, Alexander Larsson wrote:
> On Wed, 2 Aug 2000, Philipp Rumpf wrote:
> > On Wed, Aug 02, 2000 at 01:13:34PM +0200, Alexander Larsson wrote:
> > > On Tue, 1 Aug 2000, Markus Thiesmeyer wrote:
> > > Well, i haven't had time to work on jffs lately so i haven't talked much
> > > about this... But, as currently implemented, writing to mmaped jffs files
> > > is serioiusly broken. Of the address space operations only readpage is
> > 
> > Note this is for 2.2 only - 2.4 properly handles filesystems that cannot be
> > modified through mmaps.  I think it might be a good idea to do:
> > 
> > diff -ur mtd/fs/jffs/inode-v22.c mtd-prumpf/fs/jffs/inode-v22.c
> > --- mtd/fs/jffs/inode-v22.c	Sun Jul 30 18:07:16 2000
> > +++ mtd-prumpf/fs/jffs/inode-v22.c	Wed Aug  2 09:39:05 2000
> > @@ -1562,13 +1562,21 @@
> >  	return 0;
> >  } /* jffs_ioctl()  */
> >  
> > +/* Don't allow shared writable mmaps - we don't handle them correctly */
> > +static int jffs_file_mmap(struct file * file, struct vm_area_struct * vma)
> > +{
> > +	if ((vma->vm_flags & VM_SHARED) && (vma->vm_flags & VM_MAYWRITE))
> > +		return -EINVAL;
> > +
> > +	return generic_file_mmap(file, vma);
> > +} /* jffs_file_mmap() */
> 
> Hmm. It can't handle private writable mmaps either. If such a thing
> exists.

It doesn't ?  A private writable mapping means all the changes the mmap()ing
process does get thrown away after the munmap, so it should work fine as long
as readpage works.

> > But do we _want_ one ?  It basically means files will be modified 4 KB at a
> > time on most systems - I think the 2.4 behaviour is nicer.
> 
> Isn't it possible to do normal writes as currently done, but mmaped writes
> are written 4k at a time. It should be fairly easy to detect when an
> append is done.

Possible, sure.  I'm just not sure it makes sense.

	Philipp


To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

  reply	other threads:[~2000-08-02 19:36 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
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 [this message]
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=20000802123623.C20345@fruits.uzix.org \
    --to=prumpf@uzix.org \
    --cc=alex@cendio.se \
    --cc=dwmw2@infradead.org \
    --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.