From mboxrd@z Thu Jan  1 00:00:00 1970
From: Trond Myklebust <trond.myklebust@fys.uio.no>
Subject: Re: NFSv4/pNFS possible POSIX I/O API standards
Date: Mon, 04 Dec 2006 10:15:36 -0500
Message-ID: <1165245336.711.176.camel@lade.trondhjem.org>
References: <20061129094815.GE6429@schatzie.adilger.int>
	 <1164795522.7557.45.camel@imp.csi.cam.ac.uk>
	 <20061129082622.GA20285@cynthia.pants.nu>
	 <20061130092548.GA1534@infradead.org>
	 <Pine.LNX.4.62.0611300916260.8918@wtf.di.newdream.net>
	 <1164950795.5761.25.camel@lade.trondhjem.org>
	 <Pine.LNX.4.62.0611302157580.10257@wtf.di.newdream.net>
	 <1164984094.5761.86.camel@lade.trondhjem.org>
	 <20061203015203.GA5656@schatzie.adilger.int>
	 <Pine.LNX.4.62.0612021830030.31986@wtf.di.newdream.net>
	 <20061204073200.GB5637@schatzie.adilger.int>
Mime-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Cc: Sage Weil <sage@newdream.net>,
	Christoph Hellwig <hch@infradead.org>,
	Brad Boyer <flar@allandria.com>,
	Anton Altaparmakov <aia21@cam.ac.uk>,
	Gary Grider <ggrider@lanl.gov>, linux-fsdevel@vger.kernel.org
Return-path: <linux-fsdevel-owner@vger.kernel.org>
Received: from pat.uio.no ([129.240.10.15]:40032 "EHLO pat.uio.no"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S936994AbWLDPRT (ORCPT <rfc822;linux-fsdevel@vger.kernel.org>);
	Mon, 4 Dec 2006 10:17:19 -0500
To: Andreas Dilger <adilger@clusterfs.com>
In-Reply-To: <20061204073200.GB5637@schatzie.adilger.int>
Sender: linux-fsdevel-owner@vger.kernel.org
List-Id: linux-fsdevel.vger.kernel.org

On Mon, 2006-12-04 at 00:32 -0700, Andreas Dilger wrote:
> > I'm wondering if a corresponding opendirplus() (or similar) would also be 
> > appropriate to inform the kernel/filesystem that readdirplus() will 
> > follow, and stat information should be gathered/buffered.  Or do most 
> > implementations wait for the first readdir() before doing any actual work 
> > anyway?
> 
> I'm not sure what some filesystems might do here.  I suppose NFS has weak
> enough cache semantics that it _might_ return stale cached data from the
> client in order to fill the readdirplus() data, but it is just as likely
> that it ships the whole thing to the server and returns everything in
> one shot.  That would imply everything would be at least as up-to-date
> as the opendir().

Whether or not the posix committee decides on readdirplus, I propose
that we implement this sort of thing in the kernel via a readdir
equivalent to posix_fadvise(). That can give exactly the barrier
semantics that they are asking for, and only costs 1 extra syscall as
opposed to 2 (opendirplus() and readdirplus()).

Cheers
  Trond