On Sat, Aug 16, 2025 at 12:09 AM Amir Goldstein <amir73il@xxxxxxxxx> wrote: > > 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. Agree to remove the restrictions. > > > Thanks, > Amir. >
