Christoph Hellwig wrote:
On Wed, Dec 06, 2006 at 03:09:10PM -0700, Andreas Dilger wrote:
While it could do that, I'd be interested to see how you'd construct
the handle such that it's immune to a malicious user tampering with it,
or saving it across a reboot, or constructing one from scratch.
Matthew Wilcox wrote:
On Thu, Dec 14, 2006 at 03:00:41PM -0600, Rob Ross wrote:
I don't think that I understand what you're saying here. The openg()
call does not perform file open (not that that is necessarily even a
first-class FS operation), it simply does the lookup.
When we were naming
We're going to clean the statlite() call up based on this (and
subsequent) discussion and post again.
Thanks!
Rob
Ulrich Drepper wrote:
Christoph Hellwig wrote:
Ulrich, this in reply to these API proposals:
I know the documents. The HECWG was actually supposed to submit an
actual draft
Matthew Wilcox wrote:
On Tue, Dec 05, 2006 at 10:07:48AM +, Christoph Hellwig wrote:
The filehandle idiocy on the other hand is way of into crackpipe land.
Right, and it needs to be discarded. Of course, there was a real
problem that it addressed, so we need to come up with an acceptable
Christoph Hellwig wrote:
On Tue, Dec 05, 2006 at 03:44:31PM -0600, Rob Ross wrote:
The openg() really just does the lookup and permission checking). The
openfh() creates the file descriptor and starts that context if the
particular FS tracks that sort of thing.
...
Well you've caught me. I
David Chinner wrote:
On Tue, Dec 05, 2006 at 05:47:16PM +0100, Latchesar Ionkov wrote:
On 12/5/06, Rob Ross [EMAIL PROTECTED] wrote:
Hi,
I agree that it is not feasible to add new system calls every time
somebody has a problem, and we don't take adding system calls lightly.
However
Matthew Wilcox wrote:
On Wed, Dec 06, 2006 at 09:04:00AM -0600, Rob Ross wrote:
The openg() solution has the following advantages to what you propose.
First, it places the burden of the communication of the file handle on
the application process, not the file system. That means less work
Ulrich Drepper wrote:
Andreas Dilger wrote:
Does this mean you are against the statlite() API entirely, or only
against
the document's use of the flag as a vague accuracy value instead of a
hard valid value?
I'm against fuzzy values. I've no problems with a bitmap specifying
that certain
David Chinner wrote:
On Wed, Dec 06, 2006 at 09:53:39AM -0600, Rob Ross wrote:
David Chinner wrote:
On Tue, Dec 05, 2006 at 05:47:16PM +0100, Latchesar Ionkov wrote:
On 12/5/06, Rob Ross [EMAIL PROTECTED] wrote:
Hi,
I agree that it is not feasible to add new system calls every time
somebody
Matthew Wilcox wrote:
On Tue, Dec 05, 2006 at 06:09:03PM +0100, Latchesar Ionkov wrote:
It could be wasteful, but it could (most likely) also be useful. Name
resolution is not that expensive on either side of the network. The
latency introduced by the single-name lookups is :)
*is* latency
Trond Myklebust wrote:
On Tue, 2006-12-05 at 10:07 +, Christoph Hellwig wrote:
...and we have pointed out how nicely this ignores the realities of
current caching models. There is no need for a readdirplus() system
call. There may be a need for a caching barrier, but AFAICS that is all.
I
run.
On 12/1/06, Rob Ross [EMAIL PROTECTED] wrote:
Hi all,
The use model for openg() and openfh() (renamed sutoc()) is n processes
spread across a large cluster simultaneously opening a file. The
challenge is to avoid to the greatest extent possible incurring O(n) FS
interactions. To do that we
Hi all,
I don't think that the group intended that there be an opendirplus();
rather readdirplus() would simply be called instead of the usual
readdir(). We should clarify that.
Regarding Peter Staubach's comments about no one ever using the
readdirplus() call; well, if people weren't
of Linux. I'm glad to
see so many people taking interest.
I look forward to further constructive discussion. Thanks,
Rob
---
Rob Ross
Mathematics and Computer Science Division
Argonne National Laboratory
Christoph Hellwig wrote:
On Wed, Nov 29, 2006 at 05:23:13AM -0700, Matthew Wilcox wrote
14 matches
Mail list logo
