From mboxrd@z Thu Jan 1 00:00:00 1970 From: Szakacsits Szabolcs Subject: Re: Efficient handling of sparse files Date: Mon, 28 Feb 2005 19:57:57 +0100 (MET) Message-ID: References: <20050228174149.GA28741@parcelfarce.linux.theplanet.co.uk> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: linux-fsdevel@vger.kernel.org Received: from mlf.linux.rulez.org ([192.188.244.13]:52486 "EHLO mlf.linux.rulez.org") by vger.kernel.org with ESMTP id S261723AbVB1S6B (ORCPT ); Mon, 28 Feb 2005 13:58:01 -0500 To: Matthew Wilcox In-Reply-To: <20050228174149.GA28741@parcelfarce.linux.theplanet.co.uk> Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Mon, 28 Feb 2005, Matthew Wilcox wrote: > This problem came up with the systemimager program which uses rsync to > install files from a master server to many clients. Red Hat has a system > user with uid 2^32-1 which causes lastlog to grow to 1.2GB in size. > rsync does understand the concept of sparse files (with the -S flag), but > it has to read every block to discover that it is indeed empty. This sucks. XFS supports what you want. I made a related benchmark some years ago, if you are interested, http://marc.theaimsgroup.com/?l=reiserfs&m=105827549109079 > I was wondering if we could introduce a new system call (or ioctl?) that, > given an fd would find the next block with data in it. I think, this is a bad idea. The XFS or the NTFS interface could be a better start. Szaka