public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: "Linda A. Walsh" <xfs@tlinx.org>
Cc: xfs-oss <xfs@oss.sgi.com>
Subject: Re: WARNING xfsdump [still] Cannot allocate memory for list of [root|non-root] attributes for nondir ino xxyz
Date: Mon, 28 Jun 2010 12:27:44 +1000	[thread overview]
Message-ID: <20100628022744.GX6590@dastard> (raw)
In-Reply-To: <4C26A51F.8020909@tlinx.org>

On Sat, Jun 26, 2010 at 06:10:55PM -0700, Linda A. Walsh wrote:
> 
> FWIW -- that bug I mentioned a few weeks back that I thought was
> gone in the latest CVS
> of xfsdump -- isn't.
> 
> It seems less frequent (maybe external attributes have been getting
> slow weeded out as
> they fail -- if it is random).
> 
> What's 'unique' about this dump -- I just copied from one partition
> to another, to resize the first,
> and this is on the copy back.
> 
> I.e. Stuff that xfs-restore just wrote has problems being read.
> 
> First problem was about 30 minutes into the 'copy'
> 
> Then about 2 more in the next half hour -- so not real often.
> 
> This is with kernel 2.6.34.
> 
> xfstools were downloaded a few weeks ago, so fairly recent.
> 
> xfsdump: WARNING: could not get list of non-root attributes for
> nondir ino 2428439: Cannot allocate memory (12)
> in @  108 MB/s, out @  0.0 kB/s,  116 GB total, buffer   6%
> fullxfsdump: status at 02:25:06: 918808/2250704 files dumped, 54.3%
> data dumped, 1800 seconds elapsed
> in @ 14.0 MB/s, out @ 14.0 MB/s,  123 GB total, buffer   0%
> fullxfsdump: status at 02:30:06: 975579/2250704 files dumped, 57.6%
> data dumped, 2100 seconds elapsed
> in @  0.0 kB/s, out @  0.0 kB/s,  135 GB total, buffer  14%
> fullxfsdump: status at 02:35:07: 1062278/2250704 files dumped, 63.2%
> data dumped, 2401 seconds elapsed
> in @  226 MB/s, out @  157 MB/s,  152 GB total, buffer  91%
> fullxfsdump: status at 02:40:06: 1191037/2250704 files dumped, 71.5%
> data dumped, 2700 seconds elapsed
> in @  0.0 kB/s, out @  0.0 kB/s,  169 GB total, buffer   0%
> fullxfsdump: status at 02:45:06: 1321397/2250704 files dumped, 79.2%
> data dumped, 3000 seconds elapsed
> in @  0.0 kB/s, out @  120 MB/s,  176 GB total, buffer  30% full
> 
> xfsdump: WARNING: could not get list of secure attributes for nondir
> ino 3929093: Cannot allocate memory (12)
> in @  0.0 kB/s, out @  118 MB/s,  177 GB total, buffer   7% full
> 
> xfsdump: WARNING: could not get list of non-root attributes for
> nondir ino 3929095: Cannot allocate memory (12)

Can you get a list of all the attributes and their sizes on the
inodes xfsdump is complaining about?

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

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

  reply	other threads:[~2010-06-28  2:25 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-27  1:10 WARNING xfsdump [still] Cannot allocate memory for list of [root|non-root] attributes for nondir ino xxyz Linda A. Walsh
2010-06-28  2:27 ` Dave Chinner [this message]
2010-06-29 22:33   ` xfs file system in process of becoming corrupt; though xfs_repair thinks it's fine! ; -/ (was xfs_dump problem...) Linda Walsh
2010-06-29 23:25     ` xfs file system in process of becoming corrupt; though xfs_repair thinks it's fine! ;-/ " Dave Chinner
2010-06-29 23:55       ` Michael Weissenbacher
2010-06-30  0:42         ` xfs file system in process of becoming corrupt; though xfs_repair thinks it's fine! ; -/ " Linda A. Walsh
2010-06-30  1:16           ` Dave Chinner
2010-06-30  2:45             ` Linda A. Walsh
2010-07-01 23:58               ` Dave Chinner
2010-07-07  3:18                 ` Linda A. Walsh
2010-07-07  5:56                   ` Linda Walsh
2010-07-07  6:36                     ` Dave Chinner
2010-07-07  9:30                       ` Linda A. Walsh
2010-07-07 21:01                         ` Linda Walsh
2010-06-30  0:01       ` Linda A. Walsh
2010-06-30  1:06         ` xfs file system in process of becoming corrupt; though xfs_repair thinks it's fine! ;-/ " Dave Chinner
2010-06-30  1:52           ` xfs file system in process of becoming corrupt; though xfs_repair thinks it's fine! ; -/ " Linda A. Walsh
2010-06-30 21:01             ` Stan Hoeppner
2010-07-07 21:40               ` utf-8' chars from Winxp machine may be problem related (was Re: xfs file system in process of becoming corrupt; though xfs_repair...) Linda A. Walsh
2010-07-07 23:40                 ` Stan Hoeppner
2010-07-08  0:38                   ` Linda A. Walsh
2010-06-30 18:25     ` xfs file system in process of becoming corrupt; though xfs_repair thinks it's fine! ; -/ (was xfs_dump problem...) Michael Monnerie
2010-06-30 23:30       ` rsync and corrupt inodes (was xfs_dump problem) Dave Chinner
2010-07-01  8:25         ` Michael Monnerie
2010-07-02  2:42           ` Dave Chinner
2010-07-02  6:21             ` Michael Monnerie
2010-07-04 22:53               ` Dave Chinner
2010-07-12 11:28                 ` Michael Monnerie
2010-07-07 21:56         ` Linda Walsh

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=20100628022744.GX6590@dastard \
    --to=david@fromorbit.com \
    --cc=xfs@oss.sgi.com \
    --cc=xfs@tlinx.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