public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Stan Hoeppner <stan@hardwarefreak.com>
To: mike@nauticaltech.com
Cc: Eric Sandeen <sandeen@sandeen.net>, xfs@oss.sgi.com
Subject: Re: 1B files, slow file creation, only AG0 used
Date: Sun, 11 Mar 2012 21:59:28 -0500	[thread overview]
Message-ID: <4F5D6690.3010006@hardwarefreak.com> (raw)
In-Reply-To: <CAEm1PvmTCaw_eSNPPvQLvwu5X7ywseOBbALxMkSLnOT9iQd6fQ@mail.gmail.com>

On 3/9/2012 11:25 PM, Michael Spiegle wrote:

> Our "1B" files are spread out evenly into a tree of 65536 directories.
>  I've read the docs, and they seem explicit about new directories
> being created in new AGs, however we are not seeing that on our
> system.  All 1B files (despite being spread out across more than 64K
> dirs) are in the first AG.  I have tried remounting the filesystem
> with inode64 (and on 3.2.9), but this behavior does not seem to change
> even if I add more files afterwards.

When using the inode32 allocator and having 64k dirs, and seeing no
files in AGs other than AG0, might this tend to suggest that these are
zero length files or similar, being stored entirely within the directory
inodes, thus occupying no extents in other AGs?  Would this tend to
explain why 'everything' is in AG0?

> As mentioned above, the inode64 mount option doesn't seem to affect
> anything.  Can you think of anything else I should check that would
> prevent this from working?

If my guess about these files is correct, mounting with inode64 and
writing additional files should create new directory inodes in other
AGs, but you still won't see file extents in those other AGs, just as
you don't in the first AG.

Are you using this XFS filesystem as a poor man's database or something
similar?  This would tend to explain a billion files, with no extents,
wholly stored in directory inodes, only in AG0, while using the inode32
allocator.

-- 
Stan

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

  reply	other threads:[~2012-03-12  2:59 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-10  2:13 1B files, slow file creation, only AG0 used Michael Spiegle
2012-03-10  4:59 ` Eric Sandeen
2012-03-10  5:25   ` Michael Spiegle
2012-03-12  2:59     ` Stan Hoeppner [this message]
2012-03-12 22:11       ` Michael Spiegle
2012-03-12  0:56 ` Dave Chinner
2012-03-12 21:54   ` Michael Spiegle
2012-03-13  0:08     ` Dave Chinner

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=4F5D6690.3010006@hardwarefreak.com \
    --to=stan@hardwarefreak.com \
    --cc=mike@nauticaltech.com \
    --cc=sandeen@sandeen.net \
    --cc=xfs@oss.sgi.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