> From: [EMAIL PROTECTED] on behalf of Nicolas Williams
> Sent: Fri 1/5/2007 18:40
> To: Halevy, Benny
> Cc: Trond Myklebust; Jan Harkes; Miklos Szeredi; nfsv4@ietf.org;
> linux-kernel@vger.kernel.org; Mikulas Patocka; linux-fsdevel@vger.kernel.org;
> Jeff Layton; Arjan van de Ven
> Subject: Re:
> We are in the process of porting RAIF to 2.6.19 right now. Should be done
> in early January. The trick is that we are trying to keep the same source
> good for a wide range of kernel versions. In fact, not too long ago we
> even were able to compile it for 2.4.24!
>
> Nikolai.
We now have R
Miklos Szeredi <[EMAIL PROTECTED]> wrote:
>> > Well, sort of. Samefile without keeping fds open doesn't have any
>> > protection against the tree changing underneath between first
>> > registering a file and later opening it. The inode number is more
>>
>> You only need to keep one-file-per-har
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
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
On Fri, Jan 05, 2007 at 12:23:04PM -0700, Matthew Wilcox wrote:
> 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 r
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 "bug" that dereferences a null ptr.
Because anyone pokin
In message <[EMAIL PROTECTED]>, Trond Myklebust writes:
> On Thu, 2007-01-04 at 19:00 -0500, Chaitanya Patti wrote:
> >
> > Hello everyone,
> >
> > In the function nfs_lookup in nfs/dir.c , the following line (line # 926):
> >
> > error = nfs_reval_fsid(nd->mnt, dir, &fhandle, &fattr);
> >
> >
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
On Fri, Jan 05, 2007 at 09:43:22AM +0100, Miklos Szeredi wrote:
> > > > > 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 wi
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 s
On Fri, Jan 05, 2007 at 12:11:17PM -0500, Shaya Potter wrote:
> I guess the question is, why shouldn't a dentry object know what
> vfsmount it belongs to is? Can it belong to multiple vfsmount objects?
> (Again, probably showing my igornance here).
If you have the same tree mounted in two places,
On Thu, Jan 04, 2007 at 12:04:14PM +0200, Benny Halevy wrote:
> I agree that the way the client implements its cache is out of the protocol
> scope. But how do you interpret "correct behavior" in section 4.2.1?
> "Clients MUST use filehandle comparisons only to improve performance, not
> for corr
On Fri, 2007-01-05 at 17:01 +0100, Trond Myklebust wrote:
> 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 ca
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 a
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
> > 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 delet
[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 ty
> 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
On Fri, 2007-01-05 at 13:22 +0100, Trond Myklebust wrote:
> On Thu, 2007-01-04 at 19:00 -0500, Chaitanya Patti wrote:
> >
> > Hello everyone,
> >
> > In the function nfs_lookup in nfs/dir.c , the following line (line # 926):
> >
> > error = nfs_reval_fsid(nd->mnt, dir, &fhandle, &fattr);
> >
>
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 blo
Well, sort of. Samefile without keeping fds open doesn't have any
protection against the tree changing underneath between first
registering a file and later opening it. The inode number is more
You only need to keep one-file-per-hardlink-group open during final
verification, checking that inod
> > Well, sort of. Samefile without keeping fds open doesn't have any
> > protection against the tree changing underneath between first
> > registering a file and later opening it. The inode number is more
>
> You only need to keep one-file-per-hardlink-group open during final
> verification, ch
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
> >
On Thu, 2007-01-04 at 19:00 -0500, Chaitanya Patti wrote:
>
> Hello everyone,
>
> In the function nfs_lookup in nfs/dir.c , the following line (line # 926):
>
> error = nfs_reval_fsid(nd->mnt, dir, &fhandle, &fattr);
>
> uses `nd' without having checked if it is NULL.
>
> Is this correct?
It
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 descrip
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 t
> > > > 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 reliabil
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 Bhattach
Trond Myklebust wrote:
> On Thu, 2007-01-04 at 12:04 +0200, Benny Halevy wrote:
>> I agree that the way the client implements its cache is out of the protocol
>> scope. But how do you interpret "correct behavior" in section 4.2.1?
>> "Clients MUST use filehandle comparisons only to improve perform
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 0
31 matches
Mail list logo
