a question for i_inode's i_size in ext2

a question for i_inode's i_size in ext2

[홍신 shin hong]

Dear ext2 maintainers

  I have a question of inode's i_size. I found that it is hard to find
any consistent synchronization mechanism that protects inode's i_size
field.
  Is there any lock or synchronization mechanism that consistently
protects i_size fields of inode objects to avoid data race?
  In inode's definition in /include/linux/fs.h, there is comment that
i_lock protects i_size but it is not clear.

Sincerely
Shin Hong

Re: a question for i_inode's i_size in ext2

[Theodore Tso]

On Fri, Sep 19, 2008 at 04:21:44PM +0900, 홍신 shin hong wrote:
> Dear ext2 maintainers
> 
>   I have a question of inode's i_size. I found that it is hard to find
> any consistent synchronization mechanism that protects inode's i_size
> field.
>   Is there any lock or synchronization mechanism that consistently
> protects i_size fields of inode objects to avoid data race?
>   In inode's definition in /include/linux/fs.h, there is comment that
> i_lock protects i_size but it is not clear.

Yes, there is; the i_size (as well as others) are protected via
i_mutex in ext2.

Regards,

					- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: a question for i_inode's i_size in ext2

[Jan Kara]

  Dear Shin Hong,

>   I have a question of inode's i_size. I found that it is hard to find
> any consistent synchronization mechanism that protects inode's i_size
> field.
>   Is there any lock or synchronization mechanism that consistently
> protects i_size fields of inode objects to avoid data race?
>   In inode's definition in /include/linux/fs.h, there is comment that
> i_lock protects i_size but it is not clear.
  As Ted said, i_size changes use i_mutex to guard them (actually,
the comment you are probably refering to speaks about i_mutex - i_lock is
something different). Reading i_size is a different matter - see
i_size_read function. We use seqlock for that - essentially we use an
atomic counter which is incremented on every change of i_size and check
that it's value before we started reading i_size and after we have
finished reading it has not changed. I hope this helps.

								Honza
-- 
Jan Kara <jack@suse.cz>
SuSE CR Labs

Re: a question for i_inode's i_size in ext2

[Theodore Tso]

On Sat, Sep 20, 2008 at 05:25:22AM +0200, Jan Kara wrote:
> Reading i_size is a different matter - see
> i_size_read function. We use seqlock for that - essentially we use an
> atomic counter which is incremented on every change of i_size and check
> that it's value before we started reading i_size and after we have
> finished reading it has not changed. I hope this helps.

Just to clarify for Shin Hong's benefit: this is necessary only on SMP
(or CONFIG_PREEMPT) 32-bit platforms in order to make sure we read a
coherent 64-bit i_size value.

						- Ted

a question for i_inode's i_size in ext2

[홍신 shin hong]

  Thank you for the answering.

  In ext2, it seems to me that inode's i_size field can be accessed
without holding i_mutex
  nor thorugh i_size_read function.

  For example, in ext2_update_inode() can be invoked without holding i_mutex.
  However, it freely access i_size field.

  Are these accesses can race with each others?


  Sincerely
  Shin Hong

Re: a question for i_inode's i_size in ext2

[Theodore Tso]

On Fri, Sep 26, 2008 at 01:52:13PM +0900, 홍신 shin hong wrote:
>   Thank you for the answering.
> 
>   In ext2, it seems to me that inode's i_size field can be accessed without
> holding i_mutex
>   nor thorugh i_size_read function.
> 
>   For example, in ext2_update_inode() can be invoked without holding
> i_mutex.
>   However, it freely access i_size field.
> 
>   Are these accesses can race with each others?
> 

ext2_update_inode() is responsible for writing the contents of the
inode to disk.  So it simply saves the current version of the object
to persistent storage.  If the inode happens to be in the middle of
being modified, the inode will be redirtied (the rule for modifying
objects like inodes is you modify them first, *then* set the dirty bit
after you are done modifying the object).  So if another kernel thread
is in the middle of updating the object, it's not a big deal; the
updated version of the inode will get written to disk later.

Ext2 has no guarantees about filesystem consistency after a crash (you
have to run fsck after a crash), so this is OK.

     	    	       	 	    	    - Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html