From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anton Altaparmakov Subject: Re: Access content of file via inodes Date: Mon, 30 May 2005 23:19:05 +0100 (BST) Message-ID: References: <4252E09B.9020606@suse.com> <1112948279.28245.4.camel@imp.csi.cam.ac.uk> <8e70aacf0505271213a6834ee@mail.gmail.com> <8e70aacf050528144424ce78ab@mail.gmail.com> <8e70aacf05053014515e301357@mail.gmail.com> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: linux-fsdevel@vger.kernel.org Return-path: Received: from ppsw-0.csi.cam.ac.uk ([131.111.8.130]:2487 "EHLO ppsw-0.csi.cam.ac.uk") by vger.kernel.org with ESMTP id S261784AbVE3WTL (ORCPT ); Mon, 30 May 2005 18:19:11 -0400 To: Martin Jambor In-Reply-To: <8e70aacf05053014515e301357@mail.gmail.com> Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org Hi, On Mon, 30 May 2005, Martin Jambor wrote: > On 5/29/05, Anton Altaparmakov 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. Well I was being simplistic. For most (I believe) fs, i_sem is use to protect against changes in i_size. So both file write and truncate are done under i_sem. They are the only ops that can change i_size. (Asid: As a consequence of this the lseek op of those fs is also done under i_sem.) > > > 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. Ah, that's a great article! Thanks for the pointer. I will be able to remove quite a few dcache flushes from ntfs now. (-: Thanks, Anton -- Anton Altaparmakov (replace at with @) Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK Linux NTFS maintainer / IRC: #ntfs on irc.freenode.net WWW: http://linux-ntfs.sf.net/ & http://www-stu.christs.cam.ac.uk/~aia21/