Re: mkfs.xfs options suitable for creating absurdly large XFS filesystems?

[Martin Steigerwald <martin@lichtvoll.de>]

Dave Chinner - 05.09.18, 00:23:
> On Tue, Sep 04, 2018 at 05:36:43PM +0200, Martin Steigerwald wrote:
> > Dave Chinner - 04.09.18, 02:49:
> > > 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.
> > 
> > Just for the fun of it during an Linux Performance analysis & tuning
> > course I held I created a 1 EiB XFS filesystem a sparse file on
> > another XFS filesystem on an SSD of a ThinkPad T520. It took
> > several hours to create, but then it was there and mountable. AFAIR
> > the sparse file was a bit less than 20 GiB.
> 
> Yup, 20GB of single sector IOs takes a long time.

Yeah. It was interesting to see that neither the CPU nor the SSD was 
fully utilized during that time tough.

> > Trying to write more data to it than the parent filesystem can hold
> > back then resulted in "lost buffer writes" or something like that
> > in kernel.log, but no visible error message to the process that
> > wrote the data.
> 
> That should mostly be fixed by now with all the error handling work
> that went into the generic writeback path a few kernel releases ago.
> Also, remember that the only guaranteed way to determine that there
> was a writeback error is to run fsync on the file, and most
> applications don't do that after writing their data.

Great. I saw the recent writeback error discussion as well.

Thanks,
-- 
Martin