From mboxrd@z Thu Jan 1 00:00:00 1970 From: Trond Myklebust Subject: Re: generic_file_llseek vs. remote_llseek Date: Tue, 22 Aug 2006 16:00:24 -0400 Message-ID: <1156276825.6921.41.camel@localhost> References: <44EB5FB2.8090005@us.ibm.com> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Cc: linux-fsdevel@vger.kernel.org Return-path: Received: from pat.uio.no ([129.240.10.4]:30899 "EHLO pat.uio.no") by vger.kernel.org with ESMTP id S1751131AbWHVUAc (ORCPT ); Tue, 22 Aug 2006 16:00:32 -0400 To: "Steve French (smfltc)" In-Reply-To: <44EB5FB2.8090005@us.ibm.com> Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Tue, 2006-08-22 at 14:49 -0500, Steve French (smfltc) wrote: > Now that generic_file_llseek locks the inode, do we need to have anyone > use remote_llseek? > > Although remote_llseek is newer, it does a lock_kernel which seems > excessive, unless it has to do with > some isize_write race issue it is trying to avoid. > > The cifs code would probably be fine with the change to the (presumably > faster) generic_file_llseek, > and perhas the nfs code as weel.. NFS has issues with isize_write(). We can't use it 'cos it presupposes that all size changes will occur under the inode->i_mutex. Unfortunately, remote servers don't take our local inode->i_mutex. Cheers, Trond