From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anton Altaparmakov Subject: Re: Access content of file via inodes Date: Sun, 29 May 2005 08:26:42 +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> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: linux-fsdevel@vger.kernel.org Return-path: Received: from ppsw-7.csi.cam.ac.uk ([131.111.8.137]:62150 "EHLO ppsw-7.csi.cam.ac.uk") by vger.kernel.org with ESMTP id S261264AbVE2H0o (ORCPT ); Sun, 29 May 2005 03:26:44 -0400 To: Martin Jambor In-Reply-To: <8e70aacf050528144424ce78ab@mail.gmail.com> Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org Hi, On Sat, 28 May 2005, Martin Jambor wrote: > On 5/28/05, Anton Altaparmakov wrote: > > > What do I have to do to when I need to append something to a file? > > > BTW, if that matters, I'll be implementing the adress_space_operations > > > of that file as well... > > > > That depends on where you want to do that from and what that file is. > > The file is a file system internal file that is used to translate > inode numbers to addresses of inodes on the disk. It cannot be > written to from userspace. When I need one more inode than I currently > have, I also need to create a new mapping info. Aha. Just like NTFS then. (-: > 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. > 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. Thus I always call it after modifying a page. Perhaps it is sometimes or even never actually needed for NTFS but I do not want to take that risk so I prefer to always call it. It certainly does not do any harm to call it except perhaps making the code a bit slower. > Thanks for your email and for any clarification, No problem. Best regards, 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/