On Thu, Jan 17, 2008 at 11:51:51PM -0800, Michael Rubin wrote:
On Jan 15, 2008 4:36 AM, Fengguang Wu [EMAIL PROTECTED] wrote:
Andrew,
This patchset mainly polishes the writeback queuing policies.
The main goals are:
(1) small files should not be starved by big dirty files
(2) sync
On Thursday 17 January 2008, Chris mason wrote:
So, I've put v0.11 out there.
Ok, back to the suspend problem I mentioned:
Jan 18 00:04:40 revo WARNING: at fs/btrfs/tree-defrag.c:74 defrag_walk_down()
Jan 18 00:04:40 revo Pid: 258, comm: btrfs/0 Not tainted 2.6.24-rc8 #1
Jan 18 00:04:40 revo
On Fri, Jan 18, 2008 at 10:35:50AM -0500, 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.
I think your cover letter may be bigger than any of the actual
patches I'm not
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 ESTALE at any
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 an
Hi.
This is a patch to enhance ESTALE error handling during the
lookup process. The error, ESTALE, can occur when out of data
dentries, stored in the dcache, is used to translate a pathname
component to a dentry. When this occurs, the dentry which
contains the pointer to the inode which refers
Hi.
This patch adds handling for the error, ESTALE, to the system
calls which take pathnames as arguments. The algorithm used
is to detect that an ESTALE error has occurred during an
operation subsequent to the lookup process and then to unwind
appropriately and then to perform the lookup
On Thursday 17 January 2008, Christian Hesse wrote:
On Thursday 17 January 2008, Chris mason wrote:
So, I've put v0.11 out there.
Ok, back to the suspend problem I mentioned:
[ oopsen ]
I get this after a suspend/resume cycle with mounted btrfs.
Looks like metadata corruption. How are
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 handling for directories by
occasionally retrying revalidation to check to see whether 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
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.
The VFS already
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 lookup_flags, struct nameidata *nd,
-
On Thu, Nov 29, 2007 at 02:41:57PM -0800, Marc Eshel wrote:
The problem seems to be with the fact that the client and server are on
the same machine. This test work fine with or without an underlaying fs
that supports locking when the client and the server are on a different
machines. Like
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
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) {
+ /*
+
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
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 ever happen
in nature.
Unless someone
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.
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
ESTALE error handling
21 matches
Mail list logo
