[Ocfs2-tools-devel] [PATCH 07/10] fsck.ocfs2 now know inline data.

[Mark Fasheh]

On Fri, Jul 18, 2008 at 04:07:07PM -0700, Joel Becker wrote:
> >
> > So now my thought is that take INLINE_DATA_FL, i_size, i_clusters as one 
> > compound judgement. So if the 2 things happens to be right, we will regard 
> > them as right.
> > 1) if INLINE_DATA_FL is set:
> >    a) if either i_size <= max_inline_data or i_clusters=0, we trust this 
> > flag and clear the error i_size or i_clusters.
> >    b) if both i_size > max_inline_data and i_clusters>0, clear the flag and 
> > go on with check_el. The only problem is how should we handle the error in 
> > check_el(any error in check_el will not make us reset INLINE_DATA_FL or if 
> > there is any error, we will trust INLINE_DATA_FL and set it back?).
> 
> 	In a normal running filesystem, INLINE_DATA_FL is kind of
> superfluous.  Having i_clusters==0 says "inline data" all by itself.  I
> mean, if i_size!=0 and i_clusters==0, the data *has* to be inline.
> Where else would it be?  But we mark INLINE_DATA_FL to say "yes,
> i_clusters==0 is OK when i_size!=0".

Actually, it doesn't. New files (directories are different in this regard)
aren't created as inline data, because they're empty and we won't really
know until the 1st write whether it's worth storing data inline. The only
thing governing whether data is inline or not is the INLINE_DATA_FL. Also
btw, you could tunefs a file system to turn on inline data, so in reality we
have zero control over this.


> 	So, if we have both INLINE_DATA_FL and i_clusters==0, we have
> two places that say data must be inline.  I think we trust that.
> 	If the file has clusters (i_clusters!=0), our classic way of
> saying "data is in clusters" is true.  But we also find INLINE_DATA_FL,
> our explicit way of saying "data is inline".  The only way to break the
> tie is with i_size.  This fits with the theory above that exactly one
> error is way more likely than exactly two.
> 	So your scheme above fits this reasoning.  Trust the two that
> match.  I think we ignore your concern at the end of (1b).  check_el()
> will not reset INLINE_DATA_FL, it will just clean up broken i_list.  A
> broken i_list could be data or just be broken, and there's no sane way
> to tell the difference.
> 
> > 2) if INLINE_DATA_FL isn't set:
> >    a) if both i_size <= max_inline_data and i_clusters=0, we set this flag.
> >    b) if either i_size > max_inline_data or i_clusters>0, we trust the file 
> > isn't inline. so go with check_el.
> 
> 	If INLINE_DATA_FL isn't set, it is a little harder.  A file can
> have i_size<=max_inline_data and still be valid if the filesystem was
> formatted without inline data but tunefs.ocfs2 turned it on later.
> 	Your (2b) is easy.  i_clusters!=0 says "not inline" loud and
> clear, and we trust all the fields.  i_size>max_inline_data strongly
> suggests that there are clusters, so we can fixup i_clusters==0.
> 	But if isize<=max_inline_data and i_clusters=0, does that
> mean inline, or a pre-tunefs file that just got i_clusters screwed up?

It could be a sparse file, actually.


So, the relationship between i_clusters, i_size and INLINE_DATA_FL goes in
one direction _only_. If INLINE_DATA_FL is set, i_size, i_clusters had
better be correct. We can't extrapolate backwards from no INLINE_DATA_FL.

By the way, there's lots of places where fsck just trusts a flag. The
important thing IMHO is that we're consistent within fsck. Given that it's
impossible to go backwards and divine that the disk really wants the
INLINE_DATA_FL set, I think our only choice is to trust it.
	--Mark

--
Mark Fasheh