All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.