Re: xfs_repair problem.

[Eric Sandeen <sandeen@sandeen.net>]

David Bernick wrote:
> I have a filesystem where an xfs_growfs went bad. We were adding
> storage to a pre-existing infrastructure and when growing, we received
> an error. 

The error you encountered would be worth mentioning in detail...

> SInce then, we've been unable to mount.
> 
> It's a large filesystem (see below) and the addition of the extra data
> has made it larger. We tried an xfs_repair but it died, as the machine
> only has 4GB RAM. 

Do you have the latest version of repair?  (xfs_repair -V; 2.10.2 is latest)

> We're going to put 32 GB in RAM and see if that
> helps. The original FS size is about 13T and the addition brought it
> to 29T.

on a 64-bit box I hope?  what kernel version?

> Since we've been unable to write or mount, we've "backed off" the
> addition and are left with our original, which we'd like to mount.

How did you back it off?  either the fs grew or it didn't; and you can't
shrink... so I guess it did not grow...

> We try to mount and get an error about the root inode not being
> readable. Makes sense as the root inode is null (according to xfs_db).
> 
> So before we run another big xfs_repair:
> 
> 1. What is the math of filesystems size, number of files and how much
> RAM is needed for such a task? Is 32 GB enough for 1/2 Billion files
> and 13 TB?
> 
> 2. Any way I can just find my rootino,rbmino,rsumino and put them in the DB?

I looked at the db output below & re-made a similar sparse fs:

[root tmp]# bc
3064987648*4096
12554189406208
quit
[root tmp]# mkfs.xfs -dfile,name=testfile,size=12554189406208
meta-data=testfile               isize=256    agcount=12,
agsize=268435455 blks
         =                       sectsz=512   attr=2
data     =                       bsize=4096   blocks=3064987648, imaxpct=5
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096
log      =internal log           bsize=4096   blocks=32768, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=0
realtime =none                   extsz=4096   blocks=0, rtextents=0
ls -lh [root tmp]# ls -l testfile
-rw-r--r-- 1 root root 12554189406208 Dec 21 09:51 testfile
[root tmp]# xfs_db testfile
xfs_db> sb 0
xfs_db> p
magicnum = 0x58465342
blocksize = 4096
dblocks = 3064987648
rblocks = 0
rextents = 0
uuid = 4b0451c8-5be4-452f-b161-a3ada3ec1a20
logstart = 1610612740
rootino = 128
rbmino = 129
rsumino = 130

so that's most likely what it should be.

> Any other advice?

post more details of how things actually fail and what happened...


> /proc/partitions:
>  253     0 13084291072 dm-0
> 

> 
> DB:

what db command?  printing sb 0 I assume but it' worth being explicit.

-Eric


> magicnum = 0x58465342
> blocksize = 4096
> dblocks = 3064987648
> rblocks = 0
> rextents = 0
> uuid = f086bb71-d67b-4cc1-b622-1f10349e6a49
> logstart = 1073741828
> rootino = null
> rbmino = null
> rsumino = null

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