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

[Joel Becker]

On Fri, Jul 18, 2008 at 04:24:35PM -0700, Mark Fasheh wrote:
> On Fri, Jul 18, 2008 at 04:07:07PM -0700, Joel Becker wrote:
> > 	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.

	New files aren't created as inline data, but they have
i_size==0.  I was speaking about i_size>0 but i_clusters==0.
	That said, you make a point about sparse files below.  A sparse
file can certainly have 0 clusters and not be inline.  Anyway, I don't
think that changes the behaviors we've described when INLINE_DATA_FL is
set.

> It could be a sparse file, actually.

	See, this is why I was like "Mark?" :-)

> 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.

	Fair enough.  No flag means assume i_list and go from there.

> 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.

	I think you are right about how we have to treat it.  I was
hoping to avoid data loss (oh, I'll treat your data as i_list and mess
it up), but there's no way to determine that sanely.

Joel

-- 

"Sometimes one pays most for the things one gets for nothing."
        - Albert Einstein

Joel Becker
Principal Software Developer
Oracle
E-mail: joel.becker at oracle.com
Phone: (650) 506-8127