From mboxrd@z Thu Jan 1 00:00:00 1970 From: Suparna Bhattacharya Subject: Re: aio_fsync Date: Wed, 6 Aug 2003 11:51:17 +0530 Sender: owner-linux-aio@kvack.org Message-ID: <20030806062117.GA11540@in.ibm.com> References: <20030718183336.GW23808@parcelfarce.linux.theplanet.co.uk> <20030726162546.2c1d97ad.akpm@osdl.org> Reply-To: suparna@in.ibm.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Matthew Wilcox , linux-aio@kvack.org, linux-fsdevel@vger.kernel.org Return-path: To: Andrew Morton Content-Disposition: inline In-Reply-To: <20030726162546.2c1d97ad.akpm@osdl.org> List-Id: linux-fsdevel.vger.kernel.org On Sat, Jul 26, 2003 at 04:25:46PM -0700, Andrew Morton wrote: > Matthew Wilcox wrote: > > > > i'm updating the Documentation/filesystem/Locking document. > > i notice that sys_fsync() takes the i_sem before calling ->fsync, but > > io_submit_one() does not take i_sem before calling ->aio_fsync. > > > > is this intentional? do we not need to protect against concurrent > > writers as sys_fsync does? > > I don't think anything implements aio_fsync(). > > But yes, the main reason for taking i_sem there is to prevent new writes > from coming in and hopelessly livelocking the fsync. > > Unless the fsync() is implemented via a radix-tree walk. That is not > livelockable: just do a sync_page_range() across the pages from 0 to > i_size. This can potentially blow some amounts of CPU if there are a lot > of pages in cache but only a handful are dirty. > > fsync() is lame. If we go ahead and implement this I would suggest that we > allow userspace to pass in a start/length which represents a subsection of > the file. That's easy to do and is a ton more useful. And all the needed > bits and pieces already exist in the O_SYNC handling in -mm: it's just a > matter of wiring it up. Yes, I think I'll go ahead and do this. Perhaps add an initial pass that goes through the mapping's dirty pages and narrows the range to cover only dirty pages. That way, we might be able to reduce some CPU cycles in the situation you mention above. If we are unlucky enough to have a dirty page at the beginning of the file and another at the end of the file, as well as loads of non-dirty pages in the page-cache then we just live with it taking a little longer. Hopefully things will usually not be that bad. Regards Suparna -- Suparna Bhattacharya (suparna@in.ibm.com) Linux Technology Center IBM Software Labs, India -- To unsubscribe, send a message with 'unsubscribe linux-aio' in the body to majordomo@kvack.org. For more info on Linux AIO, see: http://www.kvack.org/aio/ Don't email: aart@kvack.org