Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755922Ab1DVSQB (ORCPT ); Fri, 22 Apr 2011 14:16:01 -0400 Received: from shawmail.shawcable.com ([64.59.128.220]:37199 "EHLO mail.shawcable.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753697Ab1DVSP6 convert rfc822-to-8bit (ORCPT ); Fri, 22 Apr 2011 14:15:58 -0400 X-Greylist: delayed 583 seconds by postgrey-1.27 at vger.kernel.org; Fri, 22 Apr 2011 14:15:58 EDT X-Cloudmark-SP-Filtered: true X-Cloudmark-SP-Result: v=1.1 cv=rhzBfl3TH6jSClqh7E8qe//hARbvbzCI0ETuu7/2kJU= c=1 sm=1 a=VhSaPAebcz0A:10 a=BLceEmwcHowA:10 a=kj9zAlcOel0A:10 a=c23vf5CSMVc0QQz9B4a6RA==:17 a=yPCof4ZbAAAA:8 a=5W0eosO1bopyU7SEx2kA:9 a=G7v-pEtmfS8SgnQ15QkA:7 a=CjuIK1q_8ugA:10 a=7DSvI1NPTFQA:10 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 X-IronPort-AV: E=Sophos;i="4.64,254,1301896800"; d="scan'208";a="536311010" X-reinject: true References: <1303414954-3315-1-git-send-email-josef@redhat.com> <20110422045054.GB17795@infradead.org> <20110422112852.GB1627@x4.trippels.de> <4DB16B72.1050702@redhat.com> <4DB1AC9D.3010706@oracle.com> <4DB1AF6F.4040706@redhat.com> <4DB1B37C.9070406@oracle.com> <4DB1B4F1.8070109@redhat.com> <4DB1B62B.3000700@oracle.com> In-Reply-To: <4DB1B62B.3000700@oracle.com> Mime-Version: 1.0 (iPhone Mail 8H7) Content-Transfer-Encoding: 8BIT Content-Type: text/plain; charset=us-ascii Message-Id: Cc: Eric Blake , Markus Trippelsdorf , Christoph Hellwig , Josef Bacik , "linux-kernel@vger.kernel.org" , "linux-btrfs@vger.kernel.org" , "linux-fsdevel@vger.kernel.org" X-Mailer: iPhone Mail (8H7) From: Andreas Dilger Subject: Re: [PATCH 1/2] fs: add SEEK_HOLE and SEEK_DATA flags Date: Fri, 22 Apr 2011 12:06:13 -0600 To: Sunil Mushran Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2100 Lines: 32 On 2011-04-22, at 11:08 AM, Sunil Mushran wrote: > On 04/22/2011 10:03 AM, Eric Blake wrote: >>> cp can read whatever blocksize it chooses. If that block contains >>> zero, it would signal cp that maybe it should SEEK_DATA and skip >>> reading all those blocks. That's all. We are not trying to achieve >>> perfection. We are just trying to reduce cpu waste. >>> >>> If the fs supports SEEK_*, then great. If it does not, then it is no >>> worse than before. >> But providing just SEEK_DATA _is_ worse than before if you don't provide >> the correct SEEK_HOLE everywhere. Because then your algorithm of trying >> lseek(SEEK_DATA) after every run of zeros in the hopes of an >> optimization is a wasted syscall, since it will just return your current >> offset every time, so you end up with more syscalls than if you had used >> the single lseek(SEEK_DATA) that returns the end of the file up front, >> and known that the remainder of the file has no holes to even try >> seeking past. > > You are over-optimizing. strace any process on your box and you > will find numerous wasted syscalls. Sure, there are lots of wasted syscalls, but in this case the cost of doing extra SEEK_DATA and SEEK_HOLE operations may be fairly costly. This involves scanning the whole disk layout, possibly over a network, which might need tens or hundreds of disk seeks to read the metadata, unlike regular SEEK_SET. Even SEEK_END is somewhat costly on a network filesystem, since the syscall needs to lock the file size in order to determine the end of the file, which can block other threads from writing to the file. So while I agree that the Linux mantra that "syscalls are cheap" is true if those syscalls don't actually do any work, I think it also ignores the cost of what some syscalls need to do behind the scenes. Cheers, Andreas-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/