I'm seeing this problem after flushing the metadata, keeping accessing some files in mcachefs and then doing umount.
On the next mount, mcachefs sigfaults. This is the debug log output I get when sigfaults:
INF|7fd8e99e5140|200515:180032:521|mcachefs-metadata.c:285:mcachefs_metadata_open|Opening metadata file '/tmp/mcachefs/ZRAID/metafile' (256 entries per metadata block, hash size=4 bytes)
LOG|7fd8e99e5140|200515:180032:521|mcachefs-metadata.c:300:mcachefs_metadata_open|Opened metafile '/tmp/mcachefs/ZRAID/metafile' at fd=3
LOG|7fd8e99e5140|200515:180032:521|mcachefs-metadata.c:344:mcachefs_metadata_open|Openned file ok.
LOG|7fd8e99e5140|200515:180032:521|mcachefs-metadata.c:354:mcachefs_metadata_open|Openned metafile '/tmp/mcachefs/ZRAID/metafile', head=0x7fd8e9998000
LOG|7fd8e99e5140|200515:180032:521|mcachefs-metadata.c:201:mcachefs_resize_metadata_map|Number of existing blocks : 1 (alloced_nb=256), current size=0
LOG|7fd8e99e5140|200515:180032:521|mcachefs-metadata.c:204:mcachefs_resize_metadata_map|Realloc from 0 to 24 in size
LOG|7fd8e99e5140|200515:180032:521|mcachefs-metadata.c:207:mcachefs_resize_metadata_map|Realloced to metadata_map=0x55c29caf0970, metadata_map_fresh=0x55c29caf0970
LOG|7fd8e99e5140|200515:180032:521|mcachefs-metadata.c:216:mcachefs_metadata_mmap_block|MMapping block=0, block_offset=0
LOG|7fd8e99e5140|200515:180032:521|mcachefs-metadata.c:1672:mcachefs_metadata_find_locked|Finding path '/'
LOG|7fd8e99e5140|200515:180032:521|mcachefs-metadata.c:1486:mcachefs_metadata_get_child|Father / (1) has an explicit child 30
LOG|7fd8e99e5140|200515:180032:521|mcachefs-metadata.c:2348:mcachefs_metadata_populate_vops|Root Id is 1
LOG|7fd8e99e5140|200515:180032:521|mcachefs-metadata.c:1486:mcachefs_metadata_get_child|Father / (1) has an explicit child 30
LOG|7fd8e99e5140|200515:180032:521|mcachefs-metadata.c:2289:mcachefs_metadata_vops_remove_previous|[VOPS] Remove previous VOPS entry .mcachefs : 30
LOG|7fd8e99e5140|200515:180032:521|mcachefs-metadata.c:1780:mcachefs_metadata_remove_children|At current=42 (father=0, d_name=)
LOG|7fd8e99e5140|200515:180032:521|mcachefs-metadata.c:1794:mcachefs_metadata_remove_children|=> removing hash 42:'0'
LOG|7fd8e99e5140|200515:180032:521|mcachefs-metadata.c:1156:mcachefs_metadata_do_remove_hash|Removing meta 42, lr 0,0, up 0 !
LOG|7fd8e99e5140|200515:180032:521|mcachefs-metadata.c:1172:mcachefs_metadata_do_remove_hash|No replacer, left=0, right=0
LOG|7fd8e99e5140|200515:180032:521|mcachefs-metadata.c:968:mcachefs_metadata_fix_double_black|Fix Double 42 BLACK left=0, right=0, up=0
LOG|7fd8e99e5140|200515:180032:521|mcachefs-metadata.c:972:mcachefs_metadata_fix_double_black|Reached root !
As I'm a little bit "affraid" of digging into the metadata code, maybe you have a better clue of what's going on.
As mcachefs seems to keep working as it should after the flush, I'm guessing there's something in the metadata that is only read at mount time, and it's not being properly reset at flush maybe?
as a workaround, removing the metafile allows the mount to work again.
I'm seeing this problem after flushing the metadata, keeping accessing some files in mcachefs and then doing umount.
On the next mount, mcachefs sigfaults. This is the debug log output I get when sigfaults:
As I'm a little bit "affraid" of digging into the metadata code, maybe you have a better clue of what's going on.
As mcachefs seems to keep working as it should after the flush, I'm guessing there's something in the metadata that is only read at mount time, and it's not being properly reset at flush maybe?
as a workaround, removing the metafile allows the mount to work again.