From: Martin Jambor <jamborm@gmail.com>
To: Anton Altaparmakov <aia21@cam.ac.uk>
Cc: linux-fsdevel@vger.kernel.org
Subject: Re: Access content of file via inodes
Date: Mon, 30 May 2005 23:51:27 +0200 [thread overview]
Message-ID: <8e70aacf05053014515e301357@mail.gmail.com> (raw)
In-Reply-To: <Pine.LNX.4.60.0505290822260.30836@hermes-1.csi.cam.ac.uk>
Hi,
On 5/29/05, Anton Altaparmakov <aia21@cam.ac.uk> wrote:
> > I implemented it usng the same approach which ext2 uses to modify its
> > directories and believe that is the corect way (by calling aops
> > prepare and commit methods). The only thing that puzzles me is that
>
> Yes that isw fine. Just note that prepare/commit write need to run under
> i_sem protection. But if you are already serializing access to the file
> some other way then you can ignore i_sem.
Do they? Documentation/filesystems/Locking only says they want their
page locked... but thanks for telling me, I will check that.
> > ext2 does not call flush_dcache_page that you suggested. Since it
> > seems to be an architecture specific function, I have no clue what so
> > ever whether I need to call it or not.
>
> Well, as far as I understand it, this function causes changes to the page
> contents to become visible on all CPUs and from all processes and needs to
> be run before you unlock a page/mark it up to date otherwise someone who
> then locks it and/or reads it will possibly read old data from the page
> that is no longer correct.
Some folks on irc sent me a link to an article that explains this
coherency stuff:
http://www.informit.com/articles/article.asp?p=29961&seqNum=6&rl=1
Basically, you need to call this only if the page might afterwards be
read from the userspace. Directories are not, so ext2 doesn't have to.
Thanks again,
Martin
next prev parent reply other threads:[~2005-05-30 21:51 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-04-05 1:23 Access content of file via inodes Kathy KN
2005-04-05 7:22 ` Christoph Hellwig
2005-04-05 17:53 ` Bryan Henderson
2005-04-06 1:27 ` Kathy KN (HK)
2005-04-06 1:53 ` Jeff Mahoney
2005-04-06 17:57 ` Bryan Henderson
2005-04-06 7:54 ` Anton Altaparmakov
2005-04-06 11:33 ` Anton Altaparmakov
2005-04-06 13:09 ` Jeffrey Mahoney
2005-04-07 5:25 ` Kathy KN (HK)
2005-04-07 6:47 ` Jeffrey Mahoney
2005-04-07 8:09 ` Anton Altaparmakov
2005-04-05 19:01 ` Jeff Mahoney
2005-04-06 1:32 ` Kathy KN (HK)
2005-04-06 1:50 ` Jeff Mahoney
2005-04-08 6:01 ` Kathy KN (HK)
2005-04-08 8:17 ` Anton Altaparmakov
2005-05-27 19:13 ` Martin Jambor
2005-05-28 15:57 ` Anton Altaparmakov
2005-05-28 21:44 ` Martin Jambor
2005-05-29 7:26 ` Anton Altaparmakov
2005-05-30 21:51 ` Martin Jambor [this message]
2005-05-30 22:19 ` Anton Altaparmakov
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=8e70aacf05053014515e301357@mail.gmail.com \
--to=jamborm@gmail.com \
--cc=aia21@cam.ac.uk \
--cc=linux-fsdevel@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;
as well as URLs for NNTP newsgroup(s).