> On 25 Apr 2017, at 19:50, Christophe de Dinechin <[email protected]> wrote:
> The cause of the abort is that we call set_extent_dirty from > check_extent_refs with rec->max_size == 0. I’ve instrumented to try to see > where we set this to 0 (see > https://github.com/c3d/btrfs-progs/tree/rhbz1435567), and indeed, we do > sometimes see max_size set to 0 in a few locations. My instrumentation shows > this: > > 78655 [1.792241:0x451fe0] MAX_SIZE_ZERO: Add extent rec 0x139eb80 max_size > 16384 tmpl 0x7fffffffd120 > 78657 [1.792242:0x451cb8] MAX_SIZE_ZERO: Set max size 0 for rec 0x139ec50 > from tmpl 0x7fffffffcf80 > 78660 [1.792244:0x451fe0] MAX_SIZE_ZERO: Add extent rec 0x139ed50 max_size > 16384 tmpl 0x7fffffffd120 > > I don’t really know what to make of it. I dig a bit deeper. We set rec->max_size = 0 in add_extent_rec_nolookup called from add_tree_backref, where we cleared the extent_record tmpl with a memset, so indeed, max_size is 0. However, we immediately after that do a lookup_cache_extent with a size of 1. So I wonder if at that stage, we should not set max_size to 1 for the newly created extent record. Opinions? Christophe -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
