linux-xfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Richard W.M. Jones" <rjones@redhat.com>
To: linux-xfs@vger.kernel.org
Subject: mkfs.xfs options suitable for creating absurdly large XFS filesystems?
Date: Mon, 3 Sep 2018 23:49:19 +0100	[thread overview]
Message-ID: <20180903224919.GA16358@redhat.com> (raw)

[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.]

I am trying to create an XFS filesystem in a partition of approx
2^63 - 1 bytes to see what happens.

This creates a 2^63 - 1 byte virtual disk and partitions it:

  # nbdkit memory size=9223372036854775807

  # modprobe nbd
  # nbd-client localhost /dev/nbd0
  # blockdev --getsize64 /dev/nbd0
  9223372036854774784
  # gdisk /dev/nbd0
  [...]
  Command (? for help): n
  Partition number (1-128, default 1):
  First sector (18-9007199254740973, default = 1024) or {+-}size{KMGTP}:
  Last sector (1024-9007199254740973, default = 9007199254740973) or {+-}size{KMGT
P}:
  Current type is 'Linux filesystem'
  Hex code or GUID (L to show codes, Enter = 8300):
  Changed type of partition to 'Linux filesystem'
  Command (? for help): w

The first problem was that the standard mkfs.xfs command will
try to trim the disk in 4 GB chunks (I believe this is a limit
imposed by the kernel APIs).  For a 8 EB image that takes forever.

However I can use the -K option to get around that:

  # mkfs.xfs -K /dev/nbd0p1
  meta-data=/dev/nbd0p1            isize=512    agcount=8388609, agsize=268435455 blks
           =                       sectsz=1024  attr=2, projid32bit=1
           =                       crc=1        finobt=1, sparse=0, rmapbt=0, reflink=0
  data     =                       bsize=4096   blocks=2251799813684987, imaxpct=1
           =                       sunit=0      swidth=0 blks
  naming   =version 2              bsize=4096   ascii-ci=0 ftype=1
  log      =internal log           bsize=4096   blocks=521728, version=2
           =                       sectsz=1024  sunit=1 blks, lazy-count=1
  realtime =none                   extsz=4096   blocks=0, rtextents=0
  mkfs.xfs: read failed: Invalid argument

I guess this indicates a real bug in mkfs.xfs.  I've not tracked down
exactly why this syscall fails yet but will see if I can find it
later.

But first I wanted to ask a broader question about whether there are
other mkfs options (apart from -K) which are suitable when creating
especially large XFS filesystems?

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW

             reply	other threads:[~2018-09-04  3:11 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-03 22:49 Richard W.M. Jones [this message]
2018-09-04  0:49 ` mkfs.xfs options suitable for creating absurdly large XFS filesystems? 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
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=20180903224919.GA16358@redhat.com \
    --to=rjones@redhat.com \
    --cc=linux-xfs@vger.kernel.org \
    /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).