[lkml]   [2002]   [Sep]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [BK-PATCH-2.5] Introduce new VFS inode cache lookup function
    On Tue, 3 Sep 2002, Jan Harkes wrote:
    > On Tue, Sep 03, 2002 at 06:20:44AM +0100, Anton Altaparmakov wrote:
    > > 2) It will return inodes that are I_FREEING or I_CLEAR. I will have to
    > > test for these in NTFS and then iput() to wash my hands clean of such
    > > garbage. And if I am not mistaken, the iput() actually will BUG().
    > If that is the case iget is broken. Perhaps it should test for these
    > states in find_inode (and find_inode_fast) and never return them. Are
    > those types of inodes still on the inode hash?

    That is of course the big question. As I said I haven't looked at this
    very closely...

    > > 4) If anything, as Christoph Hellwig suggested to me on #kernel,
    > > iget{,5}_locked() should be reimplemented in terms of my ilookup()
    > > implementation and not vice versa. (-:
    > Well, considering that this function (modulo the I_FREEING|I_CLEAR test
    > is identical to the first 10 lines in iget5_locked, this could call that
    > function. Ofcourse iget_locked is using the 'fast' version of find_inode.

    Yes, indeed, and yes. I recall that Al wanted the _fast() versions to
    remain separate. This can be done easily enough here, too. For example
    ilookup() and ilookup5() (to remain consistent with iget5() or if you
    have a better idea for a name...).

    Best regards,

    Anton Altaparmakov <aia21 at> (replace at with @)
    Linux NTFS maintainer / IRC: #ntfs on
    WWW: &

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:28    [W:0.023 / U:30.796 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site