> > }
> > break;
> > + case OP_INSERT_RANGE:
> > + if (!insert_range_calls) {
> > + log4(OP_SKIPPED, OP_INSERT_RANGE, offset, size);
> > + goto out;
> > + }
> > + break;
> > }
> >
> > switch (op) {
> > @@ -1244,6 +1313,21 @@ test(void)
> > }
> > do_collapse_range(offset, size);
> > break;
> > + case OP_INSERT_RANGE:
> > + TRIM_OFF_LEN(offset, size, (maxfilelen - 1) - file_size);
>
> I see a ton of "skipping insert beyond EOF" messages when I run fsx with
> this patch that boil down to that we trim against the max allowable file
> size increase rather than the current file size. I suspect the intent
> here is to not limit the insert length based on the file size. That
> makes sense, but that causes us to fail to mod the insert offset against
> the file size and thus generate a ton more noise.
>
> Could we either open code the trim to handle the offset/len correctly or
> break up the macro in a way that facilitates doing so? For example, a
> quick solution might be to create TRIM_OFF() and TRIM_LEN() based on the
> associated code in TRIM_OFF_LEN(), redefine TRIM_OFF_LEN() to use the
> new macros, and then the insert range code could do something like:
>
> TRIM_OFF(offset, file_size - 1);
> TRIM_LEN(offset, size, maxfilelen - file_size);
> ...
>
Okay, I will change it as your suggestion.
> Brian
>
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
