From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Morton Subject: Re: aio_fsync Date: Sat, 26 Jul 2003 16:25:46 -0700 Sender: owner-linux-aio@kvack.org Message-ID: <20030726162546.2c1d97ad.akpm@osdl.org> References: <20030718183336.GW23808@parcelfarce.linux.theplanet.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: linux-aio@kvack.org, linux-fsdevel@vger.kernel.org Return-path: To: Matthew Wilcox In-Reply-To: <20030718183336.GW23808@parcelfarce.linux.theplanet.co.uk> List-Id: linux-fsdevel.vger.kernel.org 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. -- 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