On Fri, Aug 15, 2025 at 5:35 PM Zorro Lang <zlang@xxxxxxxxxx> wrote: > > On Fri, Aug 15, 2025 at 05:16:51PM +0200, Amir Goldstein wrote: > > On Fri, Aug 15, 2025 at 4:47 PM Zorro Lang <zlang@xxxxxxxxxx> wrote: > > > > > > When we runs overlay/005 on a system without xfs module, it always > > > fails as "unknown filesystem type xfs", due to this case require xfs > > > to be the underlying fs explicitly: > > > > > > $MKFS_XFS_PROG -f -n ftype=1 $upper_loop_dev >>$seqres.full 2>&1 > > > > > > So notrun this case if the underlying fs isn't 'xfs'. > > > > It would have been better if instead of mkfs.xfs, we would have > > used a helper to format $upper_loop_dev as $OVL_BASE_FSTYP > > > > But this is easier, so unless anybody wants to take on the better fix > > > > Acked-by: Amir Goldstein <amir73il@xxxxxxxxx> > > Thanks Amir, No matter what kinds of underlying fs are all good? > All I know is what I read in the comments and git history. The documented kernel commit has nothing to do with xfs. > I saw this case use: > > $MKFS_XFS_PROG -f -n ftype=1 $upper_loop_dev > > So I thought it need the xfs ftype feature :-D > Ha no. Overlayfs needs underlying support for readdir d_type but ftype is the default for xfs for a long long time. I think that when Xiong Zhou wrote tests 003,004,0005: https://lore.kernel.org/fstests/1461241438-24238-1-git-send-email-xzhou@xxxxxxxxxx/ One of the tests was supposed to test the non-default ftype=0 config and then 005 used explicit ftype=1, but I am pretty sure that ftype=1 was the default long before those tests were written. IOW, any the loop devices could be formatted with any base fs. The only thing that matters for the test is the small size of the formatted loop devices. Thanks, Amir.
