Thanks for the help so far:
It my output was from "sb 0". Thanks for reminding me to be explicit.
The system is a 64-bit system with 32-GB of RAM. It's going through the FS
right now with XFS repair.
Output of xfs_repair says, "arno=3" and about 81.6% of RAM is used by the
process. Think 32 G will be enough to handle this task?
I actually don't KNOW the original error, unfortunately, when growing. I
came into this late.
We're using repair 2.9.4. Worth getting a more recent version?
Kernel is - 2.6.18-92.1.1.el5
I "backed off" by vgsplit-ing the new physical device from the original
vgroup, so I was left with my original partition. I am hoping to mount the
original device since the "expanded" fs didn't work. I am hoping xfs_repair
Why do you say its a "sparse" fs?
How do you go about writing to these inodes with these values:
rootino = 128
rbmino = 129
rsumino = 130
without affecting the data?
Thanks for any help!
On Sun, Dec 21, 2008 at 10:55 AM, Eric Sandeen <sandeen@xxxxxxxxxxx> wrote:
> 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
> > 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
> I looked at the db output below & re-made a similar sparse fs:
> [root tmp]# bc
> [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.
> > magicnum = 0x58465342
> > blocksize = 4096
> > dblocks = 3064987648
> > rblocks = 0
> > rextents = 0
> > uuid = f086bb71-d67b-4cc1-b622-1f10349e6a49
> > logstart = 1073741828
> > rootino = null
> > rbmino = null
> > rsumino = null
[[HTML alternate version deleted]]