On Wed, Aug 31, 2022 at 09:53:55AM +0800, Murphy Zhou wrote:
> Oops.. Darrick left a workaround in the xfsprogs code for fstests. My
> test setup missed TEST_DEV export somehow and the workaround was not
> working.
>
> Nevermind for this patchset.. My bloody hours...
Thanks for reminding me, I just checked that patch, and yes:
+ /*
+ * fstests has a large number of tests that create tiny filesystems to
+ * perform specific regression and resource depletion tests in a
+ * controlled environment. Avoid breaking fstests by allowing
+ * unsupported configurations if TEST_DIR, TEST_DEV, and QA_CHECK_FS
+ * are all set.
+ */
+ if (getenv("TEST_DIR") && getenv("TEST_DEV") && getenv("QA_CHECK_FS"))
+ return;
So we need to set QA_CHECK_FS to use this workaround... that's a little tricky
for xfsprogs, I never thought it would like to do this.
Your patchset is still helpful, I think it's still worth dealing with the minimal
fs size situation, better to make it configurable, or can be detected automatically.
For example:
# A workaround in xfsprogs can break the limitation of xfs minimal size
if [ -n "$QA_CHECK_FS" ];then
export XFS_MIN_SIZE=$((300 * 1024 * 1024))
else
export XFS_MIN_SIZE=$((16 * 1024 * 1024)) # or "unlimited"??
fi
...
init_min_fs_size()
{
if [ -n "$FS_MIN_SIZE" ];then
return
fi
case $FSTYP in
xfs)
FS_MIN_SIZE=$XFS_MIN_SIZE
;;
*)
FS_MIN_SIZE="unlimited" # or a big enough size??
;;
esac
}
But a configurable FS_MIN_SIZE might break some golden image. Hmm... need think
about it more, any suggestions are welcome :)
Thanks,
Zorro
>
> On Wed, Aug 31, 2022 at 8:18 AM Murphy Zhou <jencce.kernel@xxxxxxxxx> wrote:
> >
> > On Wed, Aug 31, 2022 at 3:07 AM Zorro Lang <zlang@xxxxxxxxxx> wrote:
> > >
> > > On Tue, Aug 30, 2022 at 07:46:40AM -0700, Darrick J. Wong wrote:
> > > > On Tue, Aug 30, 2022 at 03:36:34PM +0800, Zorro Lang wrote:
> > > > > On Tue, Aug 30, 2022 at 12:44:30PM +0800, Murphy Zhou wrote:
> > > > > > Since this xfsprogs commit:
> > > > > > 6e0ed3d19c54 mkfs: stop allowing tiny filesystems
> > > > > > XFS requires filesystem size bigger then 300m.
> > > > >
> > > > > I'm wondering if we can just use 300M, or 512M is better. CC linux-xfs to
> > > > > get more discussion about how to deal with this change on mkfs.xfs.
> > > > >
> > > > > >
> > > > > > Increase thoese numbers to 512M at least. There is no special
> > > > > > reason for the magic number 512, just double it from original
> > > > > > 256M and being reasonable small.
> > > > >
> > > > > Hmm... do we need a global parameter to define the minimal XFS size,
> > > > > or even minimal local fs size? e.g. MIN_XFS_SIZE, or MIN_FS_SIZE ...
> > > >
> > > > I think it would be a convenient time to create a helper to capture
> > > > that, seeing as the LTP developers recently let slip that they have such
> > > > a thing somewhere, and min fs size logic is scattered around fstests.
> > >
> > > It's a little hard to find out all cases which use the minimal fs size.
> > > But for xfs, I think we can do that with this chance. We can have:
> > >
> > > export XFS_MIN_SIZE=$((300 * 1024 * 1024))
> > > export XFS_MIN_LOG_SIZE=$((64 * 1024 * 1024))
> > >
> > > at first, then init minimal $FSTYP size likes:
> > >
> > > init_min_fs_size()
> > > {
> > > case $FSTYP in
> > > xfs)
> > > FS_MIN_SIZE=$XFS_MIN_SIZE
> > > ;;
> > > *)
> > > FS_MIN_SIZE="unlimited" # or a big enough size??
> > > ;;
> > > esac
> > > }
> > >
> > > Then other fs can follow this to add their size limitation.
> > > Any better ideas?
> >
> > In generic/042 f2fs has a similar kind of limitation.
> >
> > Let me check how LTP guys handle this.
> >
> > Thanks,
> > Murphy
> >
> > >
> > > Thanks,
> > > Zorro
> > >
> > > >
> > >
> > snipped
> > >
>
