Jean noel Cordenner wrote:
hi,
Peter Staubach a écrit :
Is the perceived performance hit really going to be as large
as suspected? We already update the time fields fairly often
and we don't pay a huge penalty for those, or at least not a
penalty that we aren't willing to pay. Has anyone
Miklos Szeredi wrote:
Would you describe the situation that would cause the kernel to
go into an infinite loop, please?
The patch basically does:
do {
...
error = inode-i_op-foo()
...
} while (error
Miklos Szeredi wrote:
In FUSE interrupts are sent to userspace, and the filesystem decides
what to do with them. So it is entirely possible and valid for a
filesystem to ignore an interrupt. If an operation was non-blocking
(such as one returning an error), then there would in fact be no
-exports the file system. This is a situation
that users have been complaining about for years and this
support can help to alleviate their situations.
Thanx...
ps
Signed-off-by: Peter Staubach [EMAIL PROTECTED]
--- linux-2.6.24.i686/fs/nfs/inode.c.org
+++ linux-2.6.24.i686/fs/nfs/inode.c
...
ps
Signed-off-by: Peter Staubach [EMAIL PROTECTED]
--- linux-2.6.24.i686/fs/namei.c.org
+++ linux-2.6.24.i686/fs/namei.c
@@ -741,7 +741,7 @@ static __always_inline void follow_dotdo
{
struct fs_struct *fs = current-fs;
- while(1) {
+ while (1) {
struct
, utime, utimes, chdir, chroot, rename, exec, mknod,
statfs, inotify, setxattr, getxattr, and listxattr. Due to
common code factoring, other system calls may have been
included too, but were not explicitly tested.
Thanx...
ps
Signed-off-by: Peter Staubach [EMAIL PROTECTED]
--- linux-2.6.24
Hi.
Here is version 2 of a patch set which modifies the system to
enhance the ESTALE error handling for system calls which take
pathnames as arguments.
The error, ESTALE, was originally introduced to handle the
situation where a file handle, which NFS uses to uniquely
identify a file on the
Trond Myklebust wrote:
On Fri, 2008-02-01 at 15:58 -0500, Peter Staubach wrote:
Hi.
The patch enhanced the ESTALE error handling for NFS mounted
file systems. It expands the number of places that the NFS
client checks for ESTALE returns from the server.
It also enhances the ESTALE
Miklos Szeredi wrote:
This doesn't apply to -mm, because the ro-mounts stuff touches a lot
of the same places as this patch. You probably need to rebase this on
top of those changes.
This patch adds handling for the error, ESTALE, to the system
calls which take pathnames as arguments. The
Miklos Szeredi wrote:
This doesn't apply to -mm, because the ro-mounts stuff touches a lot
of the same places as this patch. You probably need to rebase this on
top of those changes.
This patch adds handling for the error, ESTALE, to the system
calls which take pathnames as
Matthew Wilcox wrote:
On Fri, Jan 18, 2008 at 10:36:01AM -0500, Peter Staubach wrote:
@@ -1025,12 +1027,27 @@ static int fastcall link_path_walk(const
mntget(save.mnt);
result = __link_path_walk(name, nd);
- if (result == -ESTALE) {
+ while (result == -ESTALE
Chuck Lever wrote:
Hi Peter-
On Jan 18, 2008, at 10:35 AM, Peter Staubach wrote:
Hi.
Here is a patch set which modifies the system to enhance the
ESTALE error handling for system calls which take pathnames
as arguments.
The VFS already handles ESTALE.
If a pathname resolution encounters
...
ps
Signed-off-by: Peter Staubach [EMAIL PROTECTED]
--- linux-2.6.23.i686/fs/namei.c.org
+++ linux-2.6.23.i686/fs/namei.c
@@ -741,7 +741,7 @@ static __always_inline void follow_dotdo
{
struct fs_struct *fs = current-fs;
- while(1) {
+ while (1
, utime, utimes, chdir, chroot, rename, exec, mknod,
statfs, inotify, setxattr, getxattr, and listxattr. Due to
common code factoring, other system calls may have been
included too, but were not explicitly tested.
Thanx...
ps
Signed-off-by: Peter Staubach [EMAIL PROTECTED]
--- linux-2.6.23
-exports the file system. This is a situation
that users have been complaining about for years and this
support can help to alleviate their situations.
Thanx...
ps
Signed-off-by: Peter Staubach [EMAIL PROTECTED]
--- linux-2.6.23.i686/fs/nfs/inode.c.org
+++ linux-2.6.23.i686/fs/nfs/inode.c
J. Bruce Fields wrote:
On Fri, Jan 18, 2008 at 11:45:52AM -0500, Peter Staubach wrote:
Matthew Wilcox wrote:
On Fri, Jan 18, 2008 at 10:36:01AM -0500, Peter Staubach wrote:
static int path_lookup_create(int dfd, const char *name,
- unsigned int
Chuck Lever wrote:
On Jan 18, 2008, at 12:30 PM, Peter Staubach wrote:
Chuck Lever wrote:
On Jan 18, 2008, at 11:55 AM, Peter Staubach wrote:
Chuck Lever wrote:
Hi Peter-
On Jan 18, 2008, at 10:35 AM, Peter Staubach wrote:
Hi.
Here is a patch set which modifies the system to enhance
J. Bruce Fields wrote:
On Fri, Jan 18, 2008 at 01:12:03PM -0500, Peter Staubach wrote:
Chuck Lever wrote:
On Jan 18, 2008, at 12:30 PM, Peter Staubach wrote:
I can probably imagine a situation where the pathname resolution
would never finish, but I am not sure that it could
Hi.
Here is a patch set which modifies the system to enhance the
ESTALE error handling for system calls which take pathnames
as arguments.
The error, ESTALE, was originally introduced to handle the
situation where a file handle, which NFS uses to uniquely
identify a file on the server, no
Chuck Lever wrote:
On Jan 18, 2008, at 11:55 AM, Peter Staubach wrote:
Chuck Lever wrote:
Hi Peter-
On Jan 18, 2008, at 10:35 AM, Peter Staubach wrote:
Hi.
Here is a patch set which modifies the system to enhance the
ESTALE error handling for system calls which take pathnames
as arguments
Miklos Szeredi wrote:
I don't think Christoph will like the patch better, regardless of how
I change the description.
Of course, I'm open to suggestion on how to improve the interface, but
I think fundamentally this is the only way to correctly deal with the
below problem.
Anyway, here's the
Miklos Szeredi wrote:
Miklos Szeredi wrote:
I don't think Christoph will like the patch better, regardless of how
I change the description.
Of course, I'm open to suggestion on how to improve the interface, but
I think fundamentally this is the only way to correctly deal with the
below
J. Bruce Fields wrote:
From: J. Bruce Fields [EMAIL PROTECTED]
As Peter Staubach says elsewhere
(http://marc.info/?l=linux-kernelm=118113649526444w=2):
The problem is that some file system such as NFSv2 and NFSv3 do
not have sufficient support to be able to support leases correctly
David Howells wrote:
Make NFS root work by creating a /root directory to satisfy the mount,
otherwise the path lookup for the mount fails with ENOENT.
Signed-off-by: David Howells [EMAIL PROTECTED]
---
init/do_mounts.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git
Miklos Szeredi wrote:
From: Miklos Szeredi [EMAIL PROTECTED]
Changes:
o moved check from __fput() to remove_vma(), which is more logical
o changed set_page_dirty() to set_page_dirty_mapping in hugetlb.c
o cleaned up #ifdef CONFIG_BLOCK mess
This patch makes writing to shared memory
Miklos Szeredi wrote:
These change still have the undesirable property that although the
modified pages may be flushed to stable storage, the metadata on
the file will not be updated until the application takes positive
action. This is permissible given the current wording in the
Miklos Szeredi wrote:
While these entry points do not actually modify the file itself,
as was pointed out, they are handy points at which the kernel gains
control and could actually notice that the contents of the file are
no longer the same as they were, ie. modified.
From the operating
Miklos Szeredi wrote:
What happens if the application overwrites what it had written some
time later? Nothing. The page is already read-write, the pte dirty,
so even though the file was clearly modified, there's absolutely no
way in which this can be used to force an update to the timestamp.
Miklos Szeredi wrote:
Inspired by Peter Staubach's patch and the resulting comments.
An updated version of the original patch was submitted to LKML
yesterday... :-)
Strange coincidence :)
file = vma-vm_file;
start
Miklos Szeredi wrote:
+int set_page_dirty_mapping(struct page *page);
This aspect of the design seems intrusive to me. I didn't see a strong
reason to introduce new versions of many of the routines just to handle
these semantics. What motivated this part of
Miklos Szeredi wrote:
Why is the flag checked in __fput()?
It's because of this bit in the standard:
If there is no such call and if the underlying file is modified
as a result of a write reference, then these fields shall be
marked for update at some time after the
Miklos Szeredi wrote:
Take this example:
fd = open()
addr = mmap(.., fd)
write(fd, ...)
close(fd)
sleep(100)
msync(addr,...)
munmap(addr)
The file times will be updated in write(), but with your patch, the
bit in the mapping will also be set.
Then in msync() the
Miklos Szeredi wrote:
This still does not address the situation where a file is 'permanently'
mmap'd, does it?
So? If application doesn't do msync, then the file times won't be
updated. That's allowed by the standard, and so portable applications
will have to call msync.
It
Miklos Szeredi wrote:
From: Miklos Szeredi [EMAIL PROTECTED]
This patch makes writing to shared memory mappings update st_ctime and
st_mtime as defined by SUSv3:
The st_ctime and st_mtime fields of a file that is mapped with
MAP_SHARED and PROT_WRITE shall be marked for update at some
Trond Myklebust wrote:
On Wed, 2007-02-21 at 19:28 +0100, Miklos Szeredi wrote:
This flag is checked in msync() and __fput(), and if set, the file
times are updated and the flag is cleared
Why not also check inside vfs_getattr?
This is the minimum, that the standard asks
Miklos Szeredi wrote:
Inspired by Peter Staubach's patch and the resulting comments.
An updated version of the original patch was submitted to LKML
yesterday... :-)
Strange coincidence :)
file = vma-vm_file;
start = vma-vm_end;
+
Bryan Henderson wrote:
Clients MUST use filehandle comparisons only to improve
performance, not for correct behavior. All clients need to
be prepared for situations in which it cannot be determined
whether two filehandles denote the same object and in such
cases, avoid making invalid assumptions
Trond Myklebust wrote:
On Wed, 2006-12-13 at 12:56 +1100, Nick Piggin wrote:
Note that these pages should be *really* rare. Definitely even for normal
filesystems I think RMW would use too much bandwidth if it were required
for any significant number of writes.
If file foo exists on
Jeff Layton wrote:
[EMAIL PROTECTED] wrote:
Doh! Thanks for explaining that. Here's a respun patch with your
suggestion
incorporated. Seems to build correctly without stdbool.h. In fact,
I don't see
a stdbool.h in Linus' tree as of this morning. Are you sure that
it's needed?
Sage Weil wrote:
On Mon, 4 Dec 2006, Peter Staubach wrote:
I think that there are several points which are missing here.
First, readdirplus(), without any sort of caching, is going to be _very_
expensive, performance-wise, for _any_ size directory. You can see this
by instrumenting any NFS
Matthew Wilcox wrote:
On Tue, Dec 05, 2006 at 05:47:16PM +0100, Latchesar Ionkov wrote:
I think that the main problem is that all these file systems resove a
path name, one directory at a time bringing the server to its knees by
the huge amount of requests. I would like to see what the
Sage Weil wrote:
On Fri, 1 Dec 2006, Trond Myklebust wrote:
I'm quite happy with a proposal for a statlite(). I'm objecting to
readdirplus() because I can't see that it offers you anything useful.
You haven't provided an example of an application which would clearly
benefit from a readdirplus()
42 matches
Mail list logo
