From: Jan Hudec <bulb@ucw.cz>
To: Christoph Hellwig <hch@infradead.org>
Cc: Shaya Potter <spotter@cs.columbia.edu>,
Jamie Lokier <jamie@shareable.org>,
linux-fsdevel@vger.kernel.org
Subject: Re: which dentry a page belongs to
Date: Sat, 24 Apr 2004 10:53:54 +0200 [thread overview]
Message-ID: <20040424085354.GC7119@vagabond> (raw)
In-Reply-To: <20040423180130.A4255@infradead.org>
[-- Attachment #1: Type: text/plain, Size: 1623 bytes --]
On Fri, Apr 23, 2004 at 18:01:30 +0100, Christoph Hellwig wrote:
> On Fri, Apr 23, 2004 at 12:52:54PM -0400, Shaya Potter wrote:
> > > in 2.4 writepage is always the result of data dirtied by mmap. In 2.6 it's
> > > also for use for data dirtied by write. Even in 2.4 there's no gurantee
> > > the mapping that dirtied the page still exists when the page is written out
> > > by the VM.
> >
> > so the mapping off the page struct will be null?
>
> No. but i_mmap and i_mmap_shared might be empty.
>
> > so is that a yes to my understanding of "multiple dentries" i.e. a
> > single inode linked into multiple places in the fs.
>
> Yes.
>
> > > > > It's also possible to find no dentries at all.
> > > >
> > > > even if in my fs's writepage() function?
> > >
> > > Yes.
> >
> > so the vm_file part of vm_area_struct will be null?
>
> You won't find a vm_area_struct at all in that case.
>
> > > You can't do that.
> >
> > Yes, I know it's evil to do and would never be accepted into the kernel
> > proper, the question I'm trying to figure out if it it's possible (with
> > a stackable fs) to version files on write.
>
> It's not evil is's fucking impossible for gods sake.
>
> you can be in writepage with page->mapping->i_mmap{,shared} beeing empty.
> No way in hell you'll ever get to a dentry.
page->mapping->host->i_dentries and first item there? Of course, inode
can survive it's last dentry. But you can make sure it won't survive
dirty!
-------------------------------------------------------------------------------
Jan 'Bulb' Hudec <bulb@ucw.cz>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
next prev parent reply other threads:[~2004-04-24 8:55 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-04-23 14:57 which dentry a page belongs to Shaya Potter
2004-04-23 15:14 ` Jamie Lokier
2004-04-23 15:42 ` Shaya Potter
2004-04-23 16:37 ` Christoph Hellwig
2004-04-23 16:52 ` Shaya Potter
2004-04-23 17:01 ` Christoph Hellwig
2004-04-23 17:18 ` Shaya Potter
2004-04-23 17:22 ` Christoph Hellwig
2004-04-23 17:32 ` Shaya Potter
2004-04-23 17:37 ` Jamie Lokier
2004-04-23 17:59 ` Shaya Potter
2004-04-23 22:13 ` Jamie Lokier
2004-04-23 18:05 ` Shaya Potter
2004-04-23 21:37 ` Jamie Lokier
2004-04-23 22:26 ` Shaya Potter
2004-04-23 22:49 ` Jamie Lokier
2004-04-25 5:23 ` Shaya Potter
2004-04-25 23:22 ` Erez Zadok
2004-04-24 8:53 ` Jan Hudec [this message]
2004-04-24 8:44 ` Jan Hudec
2004-04-24 9:20 ` Christoph Hellwig
2004-04-24 9:32 ` Jan Hudec
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=20040424085354.GC7119@vagabond \
--to=bulb@ucw.cz \
--cc=hch@infradead.org \
--cc=jamie@shareable.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=spotter@cs.columbia.edu \
/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.