From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dave Chinner Subject: Re: [LSF/MM TOPIC] [ATTEND] Container disk quota and lseek(2) upon shared extents Date: Wed, 30 Jan 2013 13:41:13 +1100 Message-ID: <20130130024113.GF7255@disturbed.disaster> References: <5107E048.6080902@oracle.com> <20130129151427.GG32246@quack.suse.cz> <5107FAB4.1010204@oracle.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Jan Kara , "linux-fsdevel@vger.kernel.org" , lsf-pc@lists.linux-foundation.org, Jim Meyering To: Jeff Liu Return-path: Received: from ipmail06.adl2.internode.on.net ([150.101.137.129]:61437 "EHLO ipmail06.adl2.internode.on.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751769Ab3A3ClX (ORCPT ); Tue, 29 Jan 2013 21:41:23 -0500 Content-Disposition: inline In-Reply-To: <5107FAB4.1010204@oracle.com> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Wed, Jan 30, 2013 at 12:37:08AM +0800, Jeff Liu wrote: > On 01/29/2013 11:14 PM, Jan Kara wrote: > > On Tue 29-01-13 22:44:24, Jeff Liu wrote: > >> I'd like to discuss the following problems on LSF: .... > >> Still sounds nothing because we have FIEMAP...:( But consider the bad interface > >> and error prone when I improving cp(1) through it for sparse files, it will extends > >> the ugly tentacles of FIEMAP into du(1) again that the maintainer of coreutils(Jim, CC-ed) > >> don't like it at all, and I also want to avoid if possible... > >> > >> How about if we add a new whence type to lseek(2) for this function? lseek has very clear > >> interface and works very well for SEEK_DATA/SEEK_HOLE, most likely could works fine for > >> shared extents IMHO. > > Well, I can hardly imagine how such lseek(2) interface would look to be > > useful for identifying shared extents among different files. Do you have > > something particular in mind? > lseek(2) is not used for identifying shared extents among files. It would be improved and > called to find out and return an desired extent which is reflinked or cloned with a particular > whence, the underlying file system should be improved accordingly. > > To say Btrfs, if we performed btrfs_ioctl_clone from source file A to target B, run du(1) > against both files, it would show double space although only 1/2 space is really used/reserved > upon COW. > > If we can mark the cloned extents of file with a special flag(to say EXTENT_MAP_CLONED), then > call lseek(fd, offset, SEEK_CLONE or ?), it would return the offset of a cloned extent which is > equal or beyond the given offset, so we can find out all the cloned extents upon a file which > would be used for the disk space accounting in user space tools. Why do you need lseek to find this? Couldn't we just add a filter option to fiemap to ensure that it only returns extents in the file that match the filter? You could then implement what you want with a single call rather than having to indirectly iterate the extent map with lseek() and then calling FIEMAP on each of the regions discovered by lseek..... Cheers, Dave. -- Dave Chinner david@fromorbit.com