Re: [RFC 1/2] ext3: enlarge blocksize and fix rec_len overflow

[Michael Tokarev <mjt@tls.msk.ru>]

Andreas Dilger wrote:
> On Jun 30, 2006  11:19 -0700, Daniel Phillips wrote:
>> OK, just to handle the 64K case, what is wrong with treating 0 as 64K?
> 
> Hmm, good question - it's impossible to have a valid rec_len of 0 bytes.
> There would need to be some special casing in the directory handling code.
> Also, it breaks some of the directory sanity checking, and since "0" is
> a common corruption pattern it isn't great to use.  We could instead use
> 0xfffc to mean 0x10000 since they are virtually the same value and the
> error checking is safe.  It isn't possible to have this as a valid value.

I understand the wishes to extend the filesystem capabilities which are
now becoming limited. I understand sometimes it's relatively easy to
"extend the width" of some on-disk fields this way.

But.

Isn't this sort of kludges (in a normally numeric field of a limited width,
introduce special normally-impossible values to mean different values) are
the ways to complicate things (code) and confuse various tools and people
for too much, making the whole thing just broken by design?

A line should be drawn somewhere.  When, after breaking (and thus "fixing")
some currently present limit, we change internal semantics in an ugly way,
maybe it's really better to change original design and introduce new,
somehow incompatible filesystem instead?

Please excuse me if this my comment is entirely beyong the point, because,
well.. to be fair, I don't quite understand what's the whole talk about,
I'm just reading the above (quoted) email out of context... ;)

/mjt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/