From: Dave Chinner <david@fromorbit.com>
To: "Richard W.M. Jones" <rjones@redhat.com>
Cc: linux-xfs@vger.kernel.org
Subject: Re: mkfs.xfs options suitable for creating absurdly large XFS filesystems?
Date: Tue, 4 Sep 2018 19:11:12 +1000 [thread overview]
Message-ID: <20180904091112.GT5631@dastard> (raw)
In-Reply-To: <20180904082600.GB16358@redhat.com>
On Tue, Sep 04, 2018 at 09:26:00AM +0100, Richard W.M. Jones wrote:
> On Tue, Sep 04, 2018 at 10:49:40AM +1000, Dave Chinner wrote:
> > On Mon, Sep 03, 2018 at 11:49:19PM +0100, Richard W.M. Jones wrote:
> > > [This is silly and has no real purpose except to explore the limits.
> > > If that offends you, don't read the rest of this email.]
> >
> > We do this quite frequently ourselves, even if it is just to remind
> > ourselves how long it takes to wait for millions of IOs to be done.
> >
> > > I am trying to create an XFS filesystem in a partition of approx
> > > 2^63 - 1 bytes to see what happens.
> >
> > Should just work. You might find problems with the underlying
> > storage, but the XFS side of things should just work.
>
> Great! How do you test this normally?
The usual: it's turtles all the way down.
> I'm assuming you must use a
> virtual device and don't have actual 2^6x storage systems around?
Right. I use XFS on XFS configurations. i.e. XFS is the storage pool
on physical storage (SSDs in RAID0 in this case). The disk images
are sparse files w/ extent size hints to minimise fragmentation and
allocation overhead. And the QEMU config uses AIO/DIO so it can do
concurrent, deeply queued async read/write IO from the guest to the
host - the guest block device behaves exactly like it is hosted on
real disks.
Apart from reflink and extent size hints, I'm using the defaults for
everything.
> > > I guess this indicates a real bug in mkfs.xfs.
> >
> > Did it fail straight away? Or after a long time? Can you trap this
> > in gdb and post a back trace so we know where it is coming from?
>
> Yes I think I was far too hasty declaring this a problem with mkfs.xfs
> last night. It turns out that NBD on the wire can only describe a few
> different errors and maps any other error to -EINVAL, which is likely
Urk. It should map them to -EIO, because then we know it's come from
the IO layer and isn't a problem related to userspace passing the
kernel invalid parameters.
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
next prev parent reply other threads:[~2018-09-04 13:35 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-03 22:49 mkfs.xfs options suitable for creating absurdly large XFS filesystems? Richard W.M. Jones
2018-09-04 0:49 ` Dave Chinner
2018-09-04 8:23 ` Dave Chinner
2018-09-04 9:12 ` Dave Chinner
2018-09-04 8:26 ` Richard W.M. Jones
2018-09-04 9:11 ` Dave Chinner [this message]
2018-09-04 9:45 ` Richard W.M. Jones
2018-09-04 15:36 ` Martin Steigerwald
2018-09-04 22:23 ` Dave Chinner
2018-09-05 7:09 ` Martin Steigerwald
2018-09-05 7:43 ` Dave Chinner
2018-09-05 9:05 ` Richard W.M. Jones
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=20180904091112.GT5631@dastard \
--to=david@fromorbit.com \
--cc=linux-xfs@vger.kernel.org \
--cc=rjones@redhat.com \
/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 NNTP newsgroup(s).