Linux-XFS Archive mirror
 help / color / mirror / Atom feed
From: Petr Vorel <pvorel@suse.cz>
To: Li Wang <liwang@redhat.com>
Cc: LTP List <ltp@lists.linux.it>, Cyril Hrubis <chrubis@suse.cz>,
	Martin Doucha <mdoucha@suse.cz>,
	"Darrick J . Wong" <djwong@kernel.org>,
	linux-xfs@vger.kernel.org,
	automated-testing@lists.yoctoproject.org
Subject: Re: [RFC PATCH 1/1] API: Allow to use xfs filesystems < 300 MB
Date: Wed, 3 Apr 2024 16:24:31 +0200	[thread overview]
Message-ID: <20240403142431.GA452858@pevik> (raw)
In-Reply-To: <CAEemH2e_t5XdGNFPOw0suGgAEbWLYPuX-tnZCoxQ1oZJZ9H2pg@mail.gmail.com>

Hi all,

> Hi Petr, All,


> Petr Vorel <pvorel@suse.cz> wrote:

> > Hi all,

> > Could we in the end accept this patch?

> > It'd fix the issue for now and I could set size of the XFS loop device
> > smaller
> > than 300 MB (better for embedded). i.e. 16 MB (or 32 or 64 MB or anything
> > higher
> > if XFS developers are convinced it's needed).


> I personally think YES!
> (sorry for replying so late, I was on vacation last week)

I still plan to implement 

Old thread thus recap Cyril's original proposal [1]

	I'm starting to wonder if we should start tracking minimal FS size per
	filesystem since btrfs and xfs will likely to continue to grow and with
	that we will end up disabling the whole fs related testing on embedded
	boards with a little disk space. If we tracked that per filesystem we
	would be able to skip a subset of filesystems when there is not enough
	space. The downside is obviously that we would have to add a bit more
	complexity to the test library.

I'm willing to implement this Cyril's proposal, but what puts me off is that
Btrfs and XFS developers are already complaining that testing on minimal size is
not a realistic testing. fstests are testing on realistic sizes, Darrick J. Wong
[2]:

	... In the ideal world we'll some day get around to restructuring
	all the xfstests that do tricky things with sub-500M filesystems, but
	that's the unfortunate part of removing support for small disks.

	Most of the fstests don't care about the fs size and so they'll run with
	the configured storage (some tens or millions of gigabytes) so we're
	mostly using the same fs sizes that users are expected to have.

Geert Uytterhoeven suggested [3]:
Yeah, we used to have ext2 root file systems that fit on 1440 KiB floppies.
IIRC, ext3 does have a minimum size of 32 MiB or so.

> > As I wrote before I plan to suggest sizes:
> > btrfs 110 MB
> > the rest (ext[234], xfs, ntfs, vfat, exfat, tmpfs): 16 MB

Maybe safer would be (from more realistic point of testing)
* Btrfs, XFS: 300 MB (keep the current size for Btrfs)
* Maybe raise ext4 to 32 MB (more realistic?)
* others: 16 MB

> +1 thanks for finding the minimal size.

Also Amir noted [4] that we have squashfs01.c asks for .dev_min_size = 1, but we
do the minimal default (300 MB now, it would be 16 MB). Do we want to force
.dev_min_size in this case or use the default minimal?

Kind regards,
Petr

[1] https://lore.kernel.org/ltp/Yv4MBF79PnJKJbwm@yuki/
[2] https://lore.kernel.org/ltp/Yv2A9Ggkv%2FNBrTd4@magnolia/
[3] https://lore.kernel.org/ltp/CAMuHMdUMBjCTwPu7wxrnagXnbyVxxmXN+vHmML0Lr=SyrTw0nQ@mail.gmail.com/
[4] https://lore.kernel.org/ltp/CAOQ4uxjMEHYQwO25dhs5WtzbOkJcee0HofQDTT3cD-qXJn7xQw@mail.gmail.com/

      parent reply	other threads:[~2024-04-03 14:24 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-17 20:40 [RFC PATCH 1/1] API: Allow to use xfs filesystems < 300 MB Petr Vorel
2022-08-17 23:59 ` Darrick J. Wong
2022-08-18  5:08   ` [LTP] " Amir Goldstein
2022-08-18  9:45     ` Petr Vorel
2022-08-18  9:01   ` Petr Vorel
2022-08-18  9:53 ` Cyril Hrubis
2022-08-18 11:12   ` Petr Vorel
2022-08-18 11:30     ` Cyril Hrubis
2022-08-18 11:55       ` [Automated-testing] " Geert Uytterhoeven
2022-08-19 19:28         ` Petr Vorel
     [not found]           ` <CAEemH2ehh1+WPtwjzere-JEHeBUpg27w4nZs6_QG71ZTAkUzpA@mail.gmail.com>
2022-08-22  9:36             ` Petr Vorel
2022-08-24 10:21 ` Petr Vorel
     [not found]   ` <CAEemH2e_t5XdGNFPOw0suGgAEbWLYPuX-tnZCoxQ1oZJZ9H2pg@mail.gmail.com>
2024-04-03 14:24     ` Petr Vorel [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20240403142431.GA452858@pevik \
    --to=pvorel@suse.cz \
    --cc=automated-testing@lists.yoctoproject.org \
    --cc=chrubis@suse.cz \
    --cc=djwong@kernel.org \
    --cc=linux-xfs@vger.kernel.org \
    --cc=liwang@redhat.com \
    --cc=ltp@lists.linux.it \
    --cc=mdoucha@suse.cz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).