Hi,
On Thu, 2007-01-04 at 21:32 -0600, Russell Cattelan wrote:
This fixes a bug found by the fsfuzzer tool.
http://projects.info-pull.com/mokb/MOKB-15-11-2006.html
A NULL was not an acceptable error condition expected
by any of the gfs2_lookupi callers.
Now applied to the GFS2 git tree.
On Fri, Jan 05, 2007 at 08:02:33AM +0100, Jens Axboe wrote:
On Fri, Jan 05 2007, Suparna Bhattacharya wrote:
On Thu, Jan 04, 2007 at 09:02:42AM -0800, Andrew Morton wrote:
On Thu, 4 Jan 2007 10:26:21 +0530
Suparna Bhattacharya [EMAIL PROTECTED] wrote:
On Wed, Jan 03, 2007 at
On Fri, Jan 05 2007, Suparna Bhattacharya wrote:
On Fri, Jan 05, 2007 at 08:02:33AM +0100, Jens Axboe wrote:
On Fri, Jan 05 2007, Suparna Bhattacharya wrote:
On Thu, Jan 04, 2007 at 09:02:42AM -0800, Andrew Morton wrote:
On Thu, 4 Jan 2007 10:26:21 +0530
Suparna Bhattacharya [EMAIL
High probability is all you have. Cosmic radiation hitting your
computer will more likly cause problems, than colliding 64bit inode
numbers ;)
Some of us have machines designed to cope with cosmic rays, and would be
unimpressed with a decrease in reliability.
With the
On Fri, 2007-01-05 at 10:28 +0200, Benny Halevy wrote:
Trond Myklebust wrote:
Exactly where do you see us violating the close-to-open cache
consistency guarantees?
I haven't seen that. What I did see is cache inconsistency when opening
the same file with different file descriptors when
Eric Sandeen wrote:
but Al felt that it was probably better to create an EIO-returner for each
actual op signature. Since so few ops share a signature, I just went ahead
created an EIO function for each individual file inode op that returns
a value.
Hmm, the problem with this is it bloats
[EMAIL PROTECTED] wrote:
Hmm, the problem with this is it bloats bad_inode.o with lots of empty
functions that return -EIO. Even though we're not interested in the
parameters, GCC doesn't know this, and doesn't fold the functions into only
the couple of definitions that return different
On Fri, 2007-01-05 at 10:00 -0500, Shaya Potter wrote:
I'd agree with you (And even told the person the problem up front)
except it's not oopsing on a lack of intent information, it's oopsing
because nd is null and therefore can not access nd-mnt.
i.e. Let say I couldn't reconstruct nd
On Fri, Jan 05, 2007 at 12:11:17PM -0500, Shaya Potter wrote:
ok, I guess what I don't understand is when are
dentry-d_sb-s_root and nd-mnt-mnt_root not equivalent.
I guess it would be when crossing a mountpoint on the server, so I
look at nfs_follow_mountpoint() and basically see that you
Hi!
Some of us have machines designed to cope with cosmic rays, and would be
unimpressed with a decrease in reliability.
With the suggested samefile() interface you'd get a failure with just
about 100% reliability for any application which needs to compare a
more than a few
And does it matter? If you rename a file, tar might skip it no matter of
hardlink detection (if readdir races with rename, you can read none of the
names of file, one or both --- all these are possible).
If you have dir1/a hardlinked to dir1/b and while tar runs you delete
both a and b
And does it matter? If you rename a file, tar might skip it no matter of
hardlink detection (if readdir races with rename, you can read none of the
names of file, one or both --- all these are possible).
If you have dir1/a hardlinked to dir1/b and while tar runs you delete
both a
On Fri, 2007-01-05 at 10:40 -0600, Nicolas Williams wrote:
What I don't understand is why getting the fileid is so hard -- always
GETATTR when you GETFH and you'll be fine. I'm guessing that's not as
difficult as it is to maintain a hash table of fileids.
You've been sleeping in class. We
For now, I'm not going to address the controversial issues here,
mainly because I haven't decided how I feel about them yet.
Whether allowing multiple filehandles per object is a good
or even reasonably acceptable idea.
What the fact that RFC3530 talks about implies about what
In message [EMAIL PROTECTED], Matthew Wilcox writes:
On Fri, Jan 05, 2007 at 02:10:06PM -0500, Erez Zadok wrote:
Ah, ok. So why not put an ASSERT in there, or at least a comment, to make
the code clearer. As it stands, anyone looking at the code in the future
can easily rediscover this
Pavel Machek [EMAIL PROTECTED] wrote:
Another idea is to export the filesystem internal ID as an arbitray
length cookie through the extended attribute interface. That could be
stored/compared by the filesystem quite efficiently.
How will that work for FAT?
Or maybe we can relax that
16 matches
Mail list logo
