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
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
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 <[email protected]>
SuSE CR Labs
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