Date: Mon, 29 Oct 2007 15:46:57 -0400
From: Chris Mason <chris.mason@oracle.com>
To: Mike Waychison <mikew@google.com>
Cc: Zach Brown <zab@zabbo.net>, Anton Altaparmakov <aia21@cam.ac.uk>,
       linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [patch 0/6][RFC] Cleanup FIBMAP
Message-ID: <20071029154657.04ddd13b@think.oraclecorp.com>
In-Reply-To: <472631FE.9070003@google.com>
References: <20071026233732.568575496@crlf.corp.google.com>
	<E579083F-FED3-4990-8E24-275ED38E9E3B@cam.ac.uk>
	<20071029101001.4378a7cf@think.oraclecorp.com>
	<47260AB1.9000003@zabbo.net>
	<472631FE.9070003@google.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2034
Lines: 48

On Mon, 29 Oct 2007 12:18:22 -0700
Mike Waychison <mikew@google.com> wrote:

> Zach Brown wrote:
> >>> And another of my pet peeves with ->bmap is that it uses 0 to
> >>> mean "sparse" which causes a conflict on NTFS at least as block
> >>> zero is part of the $Boot system file so it is a real, valid
> >>> block...  NTFS uses -1 to denote sparse blocks internally.
> >> Reiserfs and Btrfs also use 0 to mean packed.  It would be nice if
> >> there was a way to indicate your-data-is-here-but-isn't-alone.
> >> But that's more of a feature for the FIEMAP stuff.
> > 
> > And maybe we can step back and see what the callers of FIBMAP are
> > doing with the results they're getting.
> > 
> > One use is to discover the order in which to read file data that
> > will result in efficient IO.
> > 
> > If we had an interface specifically for this use case then perhaps a
> > sparse block would be better reported as the position of the inode
> > relative to other data blocks.  Maybe the inode block number in
> > ext* land.
> > 
> 
> Can you clarify what you mean above with an example?  I don't really
> follow.

This is a larger topic of helping userland optimize access to groups of
files.  For example, during a readdir if we knew the next step was to
delete all the files found, we could do one top of readahead (or even
ordering the returned values).

If we knew the next step would be to read all the files found, a
different type of readahead would be useful.

But, we shouldn't inflict all of this on fibmap/fiemap....we'll get
lost trying to make the one true interface for all operations.

For grouping operations on files, I think a read_tree syscall with
hints for what userland will do (read, stat, delete, list
filenames), and a better cookie than readdir should do it.

-chris
-
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/