All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michael Weissenbacher <mw@dermichi.com>
To: xfs@oss.sgi.com
Subject: xfs_bmap Cannot allocate memory
Date: Tue, 05 Jul 2011 07:02:56 +0200	[thread overview]
Message-ID: <4E129B00.4020709@dermichi.com> (raw)

Hi List!
I've got a file here on which i cannot use xfs_bmap to determine it's
fragments. All that i know is that it must have a really great number of
them. It was the result of running a smbd without strict allocate. The
machine itself has 8GiB of RAM and 10GiB of swap available, so that
shouldn't be the problem. I guess this is some bug in xfs_bmap. Or is it
a known limitation?

# xfs_bmap /backup/tmp/cannot_allocate_memory.vhd
xfs_bmap: xfsctl(XFS_IOC_GETBMAPX) iflags=0x0
["/backup/tmp/cannot_allocate_memory.vhd"]: Cannot allocate memory

Another thing i noticed is that when i use the filefrag utility it
reports a different fragment count when invoked with -v than without it,
which i found pretty strange too. From that output i judge that the real
count is 62715, which is also not in sync with 45487.
# filefrag /backup/tmp/cannot_allocate_memory.vhd
/backup/tmp/cannot_allocate_memory.vhd: 1364 extents found
# filefrag -v /backup/tmp/cannot_allocate_memory.vhd | tail -n5
62711 43265805  57280748  57265654     17
62712 43266061  57265655  57280764      1
62713 43266317  57396971  57265655     17
62714 43266573  57265656  57396987      1 eof
/backup/tmp/cannot_allocate_memory.vhd: 45487 extents found

Other than that everything works perfectly well and xfs_repair doesn't
report any problems with the filesystem. So it's only a "cosmetical" issue.

Thanks for any hints,
Michael

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

             reply	other threads:[~2011-07-05  5:03 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-07-05  5:02 Michael Weissenbacher [this message]
2011-07-05 10:32 ` xfs_bmap Cannot allocate memory Dave Chinner
2011-07-05 10:44   ` Michael Weissenbacher
2011-07-05 11:39     ` Dave Chinner
2011-07-05 13:18       ` Michael Weissenbacher
2011-07-05 10:35 ` Stan Hoeppner
2011-07-05 11:08   ` Michael Weissenbacher
2011-07-05 10:49 ` Christoph Hellwig
2011-07-05 11:01   ` Michael Weissenbacher

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=4E129B00.4020709@dermichi.com \
    --to=mw@dermichi.com \
    --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 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.