[Ocfs2-devel] question for lvb->lvb_igeneration

[Ocfs2-devel] question for lvb->lvb_igeneration

[Coly Li]

Hi,

As my understanding, inode->i_generation only gets updated when inode with same inode number is recreated.
When truncating a file, the modification of di->i_size will not update the inode->i_generation. Therefore, I suspicious
it's problematic in following condition.

1) in ocfs2_inode_lock_update(), if ocfs2_meta_lvb_is_trustable() returns 1, update inode->i_size from lvb->lvb_isize by
ocfs2_refresh_inode_from_lvb().
2) If the inode's di->i_size is changed, and not updated to lvb->lvb_isize (can this happen ?),
ocfs2_meta_lvb_is_trustable() still returns 1, while inode->i_size still updates from lvb->lvb_isize.
3) When di->i_size != lvb->lvb_isize, when execution goes into ocfs2_truncate_file() from ocfs2_setattr(), a
mlog_bug_on_msg((le64_to_cpu(fe->i_size) != i_size_read(inode), ...) will be triggered.

My question is, is it possible that same inode's lvb->lvb_size and di->i_size can be different ? And if an inode lvb is
really trustable when ocfs2_meta_lvb_is_trustable() returns 1 ?

The reason why I ask this question, is because of bnc#591039 (https://bugzilla.novell.com/show_bug.cgi?id=591039).

Thanks.
-- 
Coly Li
SuSE Labs

[Ocfs2-devel] question for lvb->lvb_igeneration

[Wengang Wang]

Hi Coly,

Let me try to comment.

On 10-03-31 09:09, Coly Li wrote:
> Hi,
> 
> As my understanding, inode->i_generation only gets updated when inode with same inode number is recreated.
> When truncating a file, the modification of di->i_size will not update the inode->i_generation. Therefore, I suspicious
> it's problematic in following condition.

Yes I think the generation don't change during the life of an inode.
The generation comparation in ocfs2_meta_lvb_is_trustable() is to make
sure it's the correct inode to refresh form lvb.

> 
> 1) in ocfs2_inode_lock_update(), if ocfs2_meta_lvb_is_trustable() returns 1, update inode->i_size from lvb->lvb_isize by
> ocfs2_refresh_inode_from_lvb().

The lvb is valid in case the prior EX holder(another node) just downgraded it
to PR or NL. So lvb carries the newest inode meta.
refreshing from lvb(in memory) is much faster than updating from disk.

> 2) If the inode's di->i_size is changed, and not updated to lvb->lvb_isize (can this happen ?),

I think this can't happen unless there is a bug.

> ocfs2_meta_lvb_is_trustable() still returns 1, while inode->i_size still updates from lvb->lvb_isize.
> 3) When di->i_size != lvb->lvb_isize, when execution goes into ocfs2_truncate_file() from ocfs2_setattr(), a
> mlog_bug_on_msg((le64_to_cpu(fe->i_size) != i_size_read(inode), ...) will be triggered.

coming to the mlog_bug_on_msg(), inode meta is already updated from
lvb(when needed), In case we did refresh from lvb, the prior EX holder
has flushed meta to disk before releasing EX lock. So reading inode
block(no cache) on this node get the newest meta.

> My question is, is it possible that same inode's lvb->lvb_size and di->i_size can be different ? And if an inode lvb is
> really trustable when ocfs2_meta_lvb_is_trustable() returns 1 ?

I think lvb is trustable. If di->i_size mismatches lvb->lvb_size, either
we are taking a wrong lvb or the di is stale.
> 
> The reason why I ask this question, is because of bnc#591039 (https://bugzilla.novell.com/show_bug.cgi?id=591039).

regards,
wengang.

[Ocfs2-devel] question for lvb->lvb_igeneration

[Coly Li]

On 03/31/2010 10:44 AM, Wengang Wang Wrote:
> Hi Coly,
> 
> Let me try to comment.
>> My question is, is it possible that same inode's lvb->lvb_size and di->i_size can be different ? And if an inode lvb is
>> really trustable when ocfs2_meta_lvb_is_trustable() returns 1 ?
> 
> I think lvb is trustable. If di->i_size mismatches lvb->lvb_size, either
> we are taking a wrong lvb or the di is stale.
>>
>> The reason why I ask this question, is because of bnc#591039 (https://bugzilla.novell.com/show_bug.cgi?id=591039).

Hi Wengang,

Thanks for the replying:-)
Another question is, in which cases when di is staled, di->i_size is different to lvb->lvb_isize ? IMHO, update the on
disk inode will take an EX lock which will update lvb->lvb_isize as well ?

-- 
Coly Li
SuSE Labs

[Ocfs2-devel] question for lvb->lvb_igeneration

[Wengang Wang]

Hi Coly,

On 10-03-31 14:11, Coly Li wrote:
> 
> 
> On 03/31/2010 10:44 AM, Wengang Wang Wrote:
> > Hi Coly,
> > 
> > Let me try to comment.
> >> My question is, is it possible that same inode's lvb->lvb_size and di->i_size can be different ? And if an inode lvb is
> >> really trustable when ocfs2_meta_lvb_is_trustable() returns 1 ?
> > 
> > I think lvb is trustable. If di->i_size mismatches lvb->lvb_size, either
> > we are taking a wrong lvb or the di is stale.
> >>
> >> The reason why I ask this question, is because of bnc#591039 (https://bugzilla.novell.com/show_bug.cgi?id=591039).
> 
> Hi Wengang,
> 
> Thanks for the replying:-)
> Another question is, in which cases when di is staled, di->i_size is different to lvb->lvb_isize ? IMHO, update the on
> disk inode will take an EX lock which will update lvb->lvb_isize as well ?

Suppose the you got the di before prior EX holder flushed changes to disk, the di could be stale.
And if the happen to be a size change on the prior EX holder, di->i_size
!= lvb->lvb_isize. Well, this case shouldn't happen unless there is bug.

lvb values are set when and only when EX holder downgrades the lock. And
the values are from in-memory inode(and/or ocfs2_inode_info). That means
no update on lvb->lvb_isize when we update meta from disk.