The following panic occurs when truncating inode which has inline
xattr to max filesize.
[] get_dnode_of_data+0x4e/0x580 [f2fs]
[] ? read_node_page+0x51/0x90 [f2fs]
[] ? get_node_page.part.34+0xb9/0x170 [f2fs]
[] truncate_blocks+0x131/0x3f0 [f2fs]
[] f2fs_truncate+0x73/0x100 [f2fs]
[] f2fs_setattr
Currently, generic_block_bmap is used in f2fs_bmap, its semantics is when
the mapping is been found, return position of target physical block,
otherwise return zero.
But, previously, when there is no mapping info for specified logical block,
f2fs_bmap will map target physical block to a uninitiali
> >
> > One thing I did notice is that fallocate() seems slow (5-6 GB/s) compared to
> other file systems for a 3TiB fallocate() [ext4 performs the same operation in
> under a second on my system)]. Is this typical/expected for F2FS? Could it be
> because I have the IO_TRACE and/or _SECURITY set in
