All of lore.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.