From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Morton Subject: Re: fs requirements for loop device? Date: Mon, 13 May 2002 14:43:25 -0700 Sender: linux-fsdevel-owner@vger.kernel.org Message-ID: <3CE0337D.AFF02E2@zip.com.au> References: <5.1.0.14.2.20020513153242.01ffa810@pop.cus.cam.ac.uk> <1021300985.1401.0.camel@jen.americas.sgi.com> <20020513174132.A23112@infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Steve Lord , Anton Altaparmakov , Urban Widmark , linux-fsdevel@vger.kernel.org Return-path: To: Christoph Hellwig List-Id: linux-fsdevel.vger.kernel.org Christoph Hellwig wrote: > > On Mon, May 13, 2002 at 09:43:05AM -0500, Steve Lord wrote: > > > ->readpage in address space operations as it uses that directly > > > (apparently, I never looked at it). > > > > You need prepare_write and commit_write too. > > And even worse you need locking rules similar to the generic file > operations in mm/filemap.c, this was for example biteing GFS/OpenGFS. > > In short: loop.c is a horrible mess nad usually only works for > fileystems using generic_file_read/generic_file_write, an exceptions > is XFS that has very similar operations to those, but due to lack of > takeing a lock I'm still not sure whether is really is 100% correct. > > An yes, I think the abuse of do_generic_file_read is a big mistake, > it should never have been exported from filemap.c. > Can anyone point at a reason why loop shouldn't use the ->read() and ->write() methods of the backing file's file_operations? AFAICS, that fixes everything, including tmpfs. -