The "+" thing seems a little odd. Why not use "||" instead? The sum of the
two returns isn't really the important thing, is it? It is that either call to
svc_close_list() returns non-zero.
Thanx...
ps
-Original Message-
From: linux-nfs-ow...@vger.kernel.org
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
purpos
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 (erro
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
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
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
-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/i
...
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) {
+
, 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-
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 serv
Linus Torvalds wrote:
On Fri, 18 Jan 2008, Ingo Oeser wrote:
Can we get "if the write to the page hits the disk, the mtime has hit the disk
already no less than SOME_GRANULARITY before"?
That is very important for computer forensics. Esp. in saving your ass!
Ok, now back again to making t
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
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 the
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 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
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 an
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
-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/
...
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) {
+
, 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]>
---
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 longer
Anton Salikhmetov wrote:
2008/1/11, Peter Staubach <[EMAIL PROTECTED]>:
Anton Salikhmetov wrote:
From: Anton Salikhmetov <[EMAIL PROTECTED]>
The patch contains changes for updating the ctime and mtime fields for memory
mapped files:
1) adding a new flag triggering u
Anton Salikhmetov wrote:
From: Anton Salikhmetov <[EMAIL PROTECTED]>
The patch contains changes for updating the ctime and mtime fields for memory
mapped files:
1) adding a new flag triggering update of the inode data;
2) implementing a helper function for checking that flag and updating ctime
Anton Salikhmetov wrote:
From: Anton Salikhmetov <[EMAIL PROTECTED]>
The patch contains changes for updating the ctime and mtime fields for memory
mapped files:
1) adding a new flag triggering update of the inode data;
2) implementing a helper function for checking that flag and updating ctime
c or close - which would be more complex.
Adding the new flag (AS_MCTIME) has been already suggested by Peter
Staubach in his first solution for this bug. Now I understand that the
AS_MCTIME flag is required for fixing the bug.
Well, that was the approach before we had I_DIRTY_PAGES. I am
still w
Rik van Riel wrote:
On Thu, 10 Jan 2008 18:56:07 +0300
"Anton Salikhmetov" <[EMAIL PROTECTED]> wrote:
However, I don't see how they will work if there has been
something like a sync(2) done after the mmap'd region is
modified and the msync call. When the inode is written out
as part of the
Rik van Riel wrote:
On Wed, 09 Jan 2008 16:06:17 -0500
[EMAIL PROTECTED] wrote:
On Wed, 09 Jan 2008 15:50:15 EST, Rik van Riel said:
Could you explain (using short words and simple sentences) what the
exact problem is?
It's like this:
Monday 9:04AM: System boots, database se
Anton Salikhmetov wrote:
Since no reaction in LKML was recieved for this message it seemed
logical to suggest closing the bug #2645 as "WONTFIX":
http://bugzilla.kernel.org/show_bug.cgi?id=2645#c15
However, the reporter of the bug, Jacob Oestergaard, insisted the
solution to be resubmitted once
Anton Salikhmetov wrote:
> From: Anton Salikhmetov <[EMAIL PROTECTED]>
>
> I would like to propose my solution for the bug #2645 from the kernel
bug tracker:
>
> http://bugzilla.kernel.org/show_bug.cgi?id=2645
>
> The Open Group defines the behavior of the mmap() function as follows.
>
> The st_
Anton Salikhmetov wrote:
From: Anton Salikhmetov <[EMAIL PROTECTED]>
I would like to propose my solution for the bug #2645 from the kernel bug
tracker:
http://bugzilla.kernel.org/show_bug.cgi?id=2645
The Open Group defines the behavior of the mmap() function as follows.
The st_ctime and st_m
Jeff Layton wrote:
On Tue, 8 Jan 2008 17:46:33 +1100
Neil Brown <[EMAIL PROTECTED]> wrote:
The comments about patch 5/6 seem sane. I'll plan to incorporate them
in the respin...
On Saturday January 5, [EMAIL PROTECTED] wrote:
@@ -357,7 +375,18 @@ lockd_down(void)
goto
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 pro
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 pa
0200, Pierre Ossman wrote:
On Wed, 03 Oct 2007 19:41:16 -0400
Trond Myklebust <[EMAIL PROTECTED]> wrote:
We also have the 64-bit inode support from RedHat/Peter Staubach.
As has been pointed[1] out[2], this will cause regressions for
non-LFS applications (
David Howells wrote:
David Howells <[EMAIL PROTECTED]> wrote:
Peter Staubach <[EMAIL PROTECTED]> wrote:
Did I miss the section where the modified semantics about which
mounted file systems can use the cache and which ones can not
was implemented?
Yes.
fs
David Howells wrote:
The attached patch makes it possible for the NFS filesystem to make use of the
network filesystem local caching service (FS-Cache).
To be able to use this, an updated mount program is required. This can be
obtained from:
http://people.redhat.com/steved/fscache/util
Jeff Layton wrote:
Make notify_change not clear the ATTR_KILL_S*ID bits in the ia_vaid that
gets passed to the setattr inode operation. This allows the filesystems
to reinterpret whether this mode change is simply intended to clear the
setuid/setgid bits.
This means that notify_change should nev
[EMAIL PROTECTED] wrote:
On Mon, 27 Aug 2007 17:43:33 EDT, "J. Bruce Fields" said:
Looks like a reasonable idea to me, thanks! Any objection to just
calling it "svc_printk" instead of "svc_printkerr"?
I also wonder whether these shouldn't all be dprintk's instead of
printk's. One misbehav
oft,intr' works just fine.
The NFS server alone can't prevent the problems Peter Staubach refers
to. Their frequency also depends on the network and the way you're
using the filesystem. (A sufficiently paranoid application accessing
the filesystem could function correctly
John Stoffel wrote:
"Peter" == Peter Staubach <[EMAIL PROTECTED]> writes:
Peter> John Stoffel wrote:
Robin> I'm bringing this up again (I know it's been mentioned here
Robin> before) because I had been told that NFS support had gotten
Robin&g
Robin Lee Powell wrote:
On Tue, Aug 21, 2007 at 01:01:44PM -0400, Peter Staubach wrote:
John Stoffel wrote:
Robin> I'm bringing this up again (I know it's been mentioned here
Robin> before) because I had been told that NFS support had gotten
Robin> better in Linux
John Stoffel wrote:
Robin> I'm bringing this up again (I know it's been mentioned here
Robin> before) because I had been told that NFS support had gotten
Robin> better in Linux recently, so I have been (for my $dayjob)
Robin> testing the behaviour of NFS (autofs NFS, specifically) under
Robin> Li
Ian Kent wrote:
Hi,
Due to a change to fs/dcache.c:d_lookup() in the 2.6 kernel whereby only
hashed dentrys are returned the negative caching of mount failures
stopped working in the autofs4 module for nobrowse mount (ie. directory
created at mount time and removed at umount or following a mount
[EMAIL PROTECTED] wrote:
To use a NFS-root for UDP jumbo frames the kernel on the client need to bring
up interface with MTU set to 9000 bytes - otherwise it cannot contact server
with jumbo frames enabled (nfs server not responding, still trying) and cannot
boot. Added a kernel parameter named '
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 --
them.
Thanx...
ps
Sign-off-by: Peter Staubach <[EMAIL PROTECTED]>
--- linux-2.6.21.i686/fs/nfs/super.c.org
+++ linux-2.6.21.i686/fs/nfs/super.c
@@ -522,6 +522,8 @@ static inline void nfs_initialise_sb(str
sb->s_magic = NFS_SUPER_MAGIC;
+ sb->s_flags |= MS_NO_LEASES
Trond Myklebust wrote:
On Tue, 2007-06-05 at 15:10 -0400, Peter Staubach wrote:
Hi.
Attached is a small patch to allow file systems to inform the file
system independent layers that they don't support file leases.
The problem is that some file system such as NFSv2 and NFSv3 do
not
Hi.
Attached is a small patch to allow file systems to inform the file
system independent layers that they don't support file leases.
The problem is that some file system such as NFSv2 and NFSv3 do
not have sufficient support to be able to support leases correctly.
In particular for these two fi
Peter Zijlstra wrote:
Commit 0b67130149b006628389ff3e8f46be9957af98aa lost the setting of tk_status
to -EIO when there was no progress with short reads.
Signed-off-by: Peter Zijlstra <[EMAIL PROTECTED]>
---
fs/nfs/read.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
Index: linux-
Andy Chittenden wrote:
Here's a sequence of packets captured at the end of a NFS connection and
the start of the next for a RH Fedora Core 6 client:
# cat ~/tmp/28852a.txt
...
As you can see in packet 3, the nfs server's sent a FIN-ACK which is
acknowledged in packet 6 by the client. So by pack
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:
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 system
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
specifications,
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 mappin
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 is
Miklos Szeredi wrote:
__fput() will be called when there are no more references to 'file',
then it will update the time if the flag is set. This applies to
regular files as well as devices.
I suspect that you will find that, for a block device, the wrong inode
gets updated. That's w
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 fil
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 wr
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:
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:
On Wed, 21 Feb 2007 18:51:52 +0100 Miklos Szeredi <[EMAIL PROTECTED]> wrote:
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_
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;
+
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 for
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 p
ogram shows the file mtime and ctime fields at
various times and these times were used to ensure that they did change and
did change in expected ways.
Thanx...
ps
Signed-off-by: Peter Staubach <[EMAIL PROTECTED]>
--- linux-2.6.20.i686/fs/buffer.c.org
+++ linux-2.6.20.i686/fs/buffer
Alex Tomas wrote:
Peter Staubach (PS) writes:
PS> Just out of curosity, what keeps i_nlink from going to 0 immediately
PS> after the new test is executed?
i_mutex in vfs_link() and vfs_unlink()
Ahhh... Okie doke, thanx!
ps
-
To unsubscribe from this list
Eric Sandeen wrote:
An update from the earlier thread, [PATCH] [RFC] remove ext3 inode
from orphan list when link and unlink race
I think this is better than the original idea of trying to handle the
race;
I've seen that the orphan inode list can get corrupted, but there may
well
be other imp
Marek Michalkiewicz wrote:
Hello,
What is the current status of the bug where modifications to file
contents made via mmap fail to update mtime of the file?
This was discussed a few months ago in this thread:
http://lkml.org/lkml/2006/5/17/138
where patches have been posted, but it seems that
Hua Zhong wrote:
Hi,
A while ago there was a discussion about supporting direct-io on tmpfs.
Here is a simple patch that does it.
1. A new fs flag FS_RAM_BASED is added and the O_DIRECT flag is ignored
if this flag is set (suggestions on a better name?)
2. Specify FS_RAM_BASED for tmpfs an
Hugh Dickins wrote:
On Thu, 4 Jan 2007, Bill Davidsen wrote:
In many cases the use of O_DIRECT is purely to avoid impact on cache used by
other applications. An application which writes a large quantity of data will
have less impact on other applications by using O_DIRECT, assuming that the
d
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?
>
> inc
linuxer linuxer wrote:
Hi, everyone:
I am a newbie, if my question waste your time, I
am sorry for that.
In clnt.c file ,call_timeout function:
I suggest the code that judge whether the network
link status is down should be added, won't they?
I tested it with one Ethernet n
y entry is created. If the allocation
fails,
then the error can be returned directly. If the creation of the directory
entry fails, then the file struct can be easily freed.
Thanx...
ps
Signed-off-by: Peter Staubach <[EMAIL PROTECTED]>
--- linux-2.6.12/fs/open.c.org 2005-08-24 10
e direct-io
subsystem.
Limiting i/o requests to INT_MAX is starting to seem a little small.
Thanx...
ps
Signed-off-by: Peter Staubach <[EMAIL PROTECTED]>
--- linux-2.6.12/fs/direct-io.c.org 2005-08-22 08:56:40.0 -0400
+++ linux-2.6.12/fs/direct-io.c 2005-08-22 08
changes,
things work as expected and quietly.
There are some user level changes required so that it can deal with
largefiles, but those are being handled separately.
Signed-off-by: Peter Staubach <[EMAIL PROTECTED]>
--- linux-2.6.12/kernel/acct.c.org 2005-06-17 15:48:29.0 -0400
+++
Trond Myklebust wrote:
må den 25.07.2005 Klokka 17:56 (+0200) skreiv Rene Scharfe:
What's your opinion of the following patch, which explicitly states the
intent of nfs_block_bits()? It still needs patch 1 and 2.
I really don't like the choice of name. If you feel you must change th
Daniel Ritz wrote:
hi
since i'm the one that put that code there in the first place i guess
i have to comment on it :)
the attached patch should also fix your problem. and it cleans up the
magic numbers a bit.
rgds
-daniel
-
[PATCH] disable read prefetch/write burst on old O2Mic
Jan Blunck wrote:
I don't want to tell where these are in general, I need an easy way to
seek to the m'th directory + offset position without reading every
single dirent. With i_sizes != 0 it is straight forward to use "the
sum of the m directory's i_sizes + offset" as the f_pos to seek to.
Jan Blunck wrote:
Also, how is lseek + readdir supposed to work in general?
This is how libc is reading directories (at least on arch s390x):
getdents() != 0
lseek() to d_off of last dirent
getdents() != 0
lseek() to d_off of last dirent
getdents() == 0
return
Therefore I really need value
Hans Reiser wrote:
Peter, do you agree with his point that mounting should be something
ordinary users can do on mountpoints they have write permission for?
Do you agree that a systematic review of user friendliness would help
NFS? Do you think that NFS should look at SFS and consider adopting
Vlad C. wrote:
--- Hans Reiser <[EMAIL PROTECTED]> wrote:
Please treat at greater length how your proposal
differs from NFS.
I think NFS is not flexible enough because:
1) NFS requires synchronization of passwd files or
NIS/LDAP to authenticate users (which themselves
require root ac
Horst von Brand wrote:
I am contacting you to express my concern over a growing trend in kernel
development. I am specifically referring to changes being made to kernel
headers that break compatibility at the userland level, where __KERNEL__
isn't #define'd.
The policy with respect to ke
83 matches
Mail list logo
