public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Chris Mason <mason@suse.com>
To: Neil Brown <neilb@cse.unsw.edu.au>, Alan Cox <alan@redhat.com>
Cc: dek_ml@konerding.com, linux-kernel@vger.kernel.org,
	nfs@lists.sourceforge.net
Subject: Re: problems with reiserfs + nfs using 2.4.2-pre4
Date: Mon, 19 Feb 2001 20:15:46 -0500	[thread overview]
Message-ID: <1633680000.982631746@tiny> (raw)
In-Reply-To: <14993.48376.203279.390285@notabene.cse.unsw.edu.au>



On Tuesday, February 20, 2001 11:40:24 AM +1100 Neil Brown
<neilb@cse.unsw.edu.au> wrote:
> 
>   When reiserfs came along, it abused this, and re-interpreted the
>   opaque datum to contain information for recalling (locating) an
>   inode - if read_inode2 was defined.  I think this is wrong.
>

I suggested to Al Viro a while ago to break iget up into two calls, and
then got sucked into something else and didn't follow up.  Independently,
he came up with the below message during a thread on fs-devel about
read_inode.  I think it is very similar to what you've described, and it
should work.  I'm willing to help integrate/code once things settle down
for 2.4.

His last paragraph is also important, I'd rather see this as a new
call...BTW, I believe XFS and GFS actually have 64 bit inode numbers, while
reiserfs has a unique 32 bit inode number (objectid) and a unique 32 bit
packing locality that are both required to find the object.

Cut n' paste from Viro's mail, beware of newline munging:

> From: Alexander Viro <viro@math.psu.edu>
> To: Steve Whitehouse <Steve@ChyGwyn.com>
> cc: linux-fsdevel@vger.kernel.org
> Subject: Re: read_inode() extra argument ?
> Date-Sent: Tuesday, December 19, 2000 06:41:42 AM -0500
>
[snip]
> Basically, read_inode() (and iget()) is _not_ a universal API. It's
> a conveniency thing for filesystems that are comfortable with it. Notice
> that quite a few filesystems do not have ->read_inode() at all.
> 
> If you need more than just an inumber to fill the inode - don't use
> iget() at all. It's just a wrong API for that kind of situations.
> 
> In all fairness, ->read_inode() should not be a method. Correct way to
> deal with that would be along the lines
> 
> --- fs/inode.c	Tue Dec 19 09:42:41 2000
> +++ fs/inode.c.new	Tue Dec 19 09:59:37 2000
> @@ -661,22 +661,10 @@
> 			 inode->i_ino = ino;
> 			 inode->i_flags = 0;
> 			 atomic_set(&inode->i_count, 1);
> -			inode->i_state = I_LOCK;
> +			inode->i_state = I_LOCK | I_NEW;
> 			 spin_unlock(&inode_lock);
>  
> 			 clean_inode(inode);
> -			sb->s_op->read_inode(inode);
> -
> -			/*
> -			 * This is special!  We do not need the spinlock
> -			 * when clearing I_LOCK, because we're guaranteed
> -			 * that nobody else tries to do anything about the
> -			 * state of the inode when it is locked, as we
> -			 * just created it (so there can be no old holders
> -			 * that haven't tested I_LOCK).
> -			 */
> -			inode->i_state &= ~I_LOCK;
> -			wake_up(&inode->i_wait);
>  
> 			 return inode;
> 		 }
> @@ -693,6 +681,20 @@
> 		 wait_on_inode(inode);
> 	 }
> 	 return inode;
> +}
> +
> +void unlock_new_inode(struct inode *inode)
> +{
> +	/*
> +	 * This is special!  We do not need the spinlock
> +	 * when clearing I_LOCK, because we're guaranteed
> +	 * that nobody else tries to do anything about the
> +	 * state of the inode when it is locked, as we
> +	 * just created it (so there can be no old holders
> +	 * that haven't tested I_LOCK).
> +	 */
> +	inode->i_state &= ~(I_LOCK|I_NEW);
> +	wake_up(&inode->i_wait);
>  }
>  
>  static inline unsigned long hash(struct super_block *sb, unsigned long
>  i_ino) --- fs/ext2/namei.c	Tue Dec 19 09:59:54 2000
> +++ fs/ext2/namei.c.new	Tue Dec 19 10:01:22 2000
> @@ -175,9 +175,12 @@
> 		 unsigned long ino = le32_to_cpu(de->inode);
> 		 brelse (bh);
> 		 inode = iget(dir->i_sb, ino);
> -
> 		 if (!inode)
> 			 return ERR_PTR(-EACCES);
> +		if (inode->i_state & I_NEW) {
> +			ext2_read_inode(inode);
> +			unlock_new_inode(inode);
> +		}
> 	 }
> 	 d_add(dentry, inode);
> 	 return NULL;
> 
> (modulo obvious changes to fs.h, exporting (or inlining)
> unlock_new_inode(), etc.)
> 
> The point being: allow filesystems to use whatever means they find
> convenient for filling the inode. All we really need from icache is an
> analog of iget() that would leave new struct inode locked, recognizable
> as new and would _not_ do anything fs-specific. Quite possibly we want a
> new function for that leaving iget() as-is so that existing callers would
> stay intact - patch above just describes the general idea.





  reply	other threads:[~2001-02-20  1:16 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-02-19  0:18 problems with reiserfs + nfs using 2.4.2-pre4 dek_ml
2001-02-19  0:37 ` Neil Brown
2001-02-19  2:56   ` dek_ml
2001-02-19  3:40     ` Neil Brown
2001-02-19 11:23       ` Alan Cox
2001-02-20  0:40         ` Neil Brown
2001-02-20  1:15           ` Chris Mason [this message]
2001-02-20  1:34             ` Neil Brown
2001-02-20  1:24           ` Alan Cox
2001-02-20  1:37             ` Neil Brown
2001-02-20  2:11             ` dek_ml
2001-02-20 22:54               ` Brian May
2001-02-20 23:30                 ` Chris Mason
2001-02-20  2:38           ` Roman Zippel
2001-02-20  9:44             ` [NFS] " Trond Myklebust
2001-02-20 14:02               ` Roman Zippel
2001-02-20 15:16                 ` Trond Myklebust
2001-02-20 16:26                   ` Roman Zippel
2001-02-21  3:02             ` Neil Brown
2001-02-21 12:43               ` [NFS] " Trond Myklebust
2001-02-19  1:55 ` Alan Cox
2001-02-19 15:37   ` Chris Mason

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1633680000.982631746@tiny \
    --to=mason@suse.com \
    --cc=alan@redhat.com \
    --cc=dek_ml@konerding.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=neilb@cse.unsw.edu.au \
    --cc=nfs@lists.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox