Re: [PATCH] xfs: don't ASSERT on corrupt ftype

[Eric Sandeen <sandeen@sandeen.net>]

On 9/8/14 8:49 AM, Eric Sandeen wrote:
> On 9/8/14 8:05 AM, Dave Chinner wrote:
>> On Sun, Sep 07, 2014 at 08:06:35PM -0500, Eric Sandeen wrote:
>>> xfs_dir3_data_get_ftype() and xfs_dir2_sf_check() get
>>> the file type off disk, but ASSERT if it's invalid:
>>>
>>>     ASSERT(type < XFS_DIR3_FT_MAX);
>>>
>>> This might be cut & paste from the "put" functions,
>>> which should be checking that they've not been passed
>>> bad values, but we shouldn't ASSERT on bad values
>>> read from disk.
>>
>> No, they weren't cut-n-paste from the put functions. They were
>> actually designed for a metadata block where bad values would not be
>> written to disk, and corrupted disk blocks would be detected by CRC
>> validation failures. So on debug kernels it's quite appropriate to
>> assert fail on a "should never, ever happen" condition.
>
> hohum, ok.

So then presumably the reason there is no ASSERT in xfs_dir3_sfe_get_ftype
(vs in xfs_dir3_data_get_ftype) is also purely intentional and
part of the design, but I'm unable to divine that logic... can you
help me out?

I guess the only way forward is to create a 3rd set of ops, and have
one for dir2, one for dir2-with-ftype, and one for dir3?  Because
in the op, there's no way to discern between the latter 2, and
know if we're previously CRC-protected or not...

-Eric

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs