So I have run across a strange situation which I hope there are some gurus out there to help. The original setup was a logical volume of 8.9TB. I extended the volume to 17.7TB and attempted to run x
Hmmm - what kernel and what version of xfsprogs are you using? (xfs_growfs -V). Also, can you post the output of the growfs command if you still have it? If not, the output of: xfs_db -r -c 'sb 0' -c
Here's the entire output: major minor #blocks name 3 0 512000 hda 3 1 511528 hda1 152 0 9523468862 etherd/e1.0 152 16 9523468862 etherd/e0.0 254 0 19046932480 dm-0 I believe dm-0 is the lvm device.
Yep, in 1k units, so: 19046932480*1024 19504058859520 and: superblock read failed, offset 19504058859520, size 2048, ag 64, rval 0 so it's trying to read a 2k (?) superblock right in the last 1k of t
sectsize = 512 sectlog = 9 So, SB reckons its a regular 512 byte sector size. Perhaps the device driver is reporting a 2K sector size from the BLKSSZGET ioctl? That'd be wierd, cos mkfs would have is
Ok, that's recent - what kernel? (uname -a) = 44TB? .... = ~283GB 160*283GB = 44TB. Hold on - 160 AGs? I saw this exact same growfs failure signature just before Christmas at a customer site on an ol
4761733120' This is quite a relief to know that this is a fairly straightforward fix! What luck that you had encountered it recently, I really appreciate the help. Here's my uname output: Linux pure
/me breathes a sigh of relief I think we have: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=20f4ebf2bf2f57c1a9abb3655391336cc90314b3 [XFS] Make growfs work for amounts
Is this supposed to be the proper output to the command above? purenas:~# for i in `seq 0 1 63`; do xfs_db -x -c "sb $i" -c 'write agcount 64' -c 'write dblock 4761733120' /dev/vg0/lv0; done agcount
... I think dave had a typo, should be dblocks with an "s" on the end. Feel free to wait for his confirmation, though, since this is surgery, after all :) -eric
fixed Any ideas on how long the xfs_repair is supposed to take on 18TB? I started it Friday nite, and it's now Tuesday afternoon. It's stuck here: Phase 5 - rebuild AG headers and trees... - reset s
Yes, it can if it's swapping like mad because you don't have enough RAM in the machine. Runtime is also detemrined by how many inodes there are in the filesystem - do you know how many there are? Als
Of days there Using version 2.9.4. I may have forgotten to allocate more swap space (as was told in the manual given to me by the vendor), so would breaking out of the repair and restarting with mor
Mark Magpayo wrote: --Original Message-- From: xfs-bounce@xxxxxxxxxxx [mailto:xfs-bounce@xxxxxxxxxxx] On Behalf Of David Chinner Sent: Tuesday, January 22, 2008 1:13 PM To: Mark Magpayo Cc: xfs@xxxxx
On Wed, 23 Jan 2008 06:40:52 +1100, Mark Magpayo <mmagpayo@xxxxxxxxxxxxx> --Original Message-- From: David Chinner [mailto:dgc@xxxxxxx] Sent: Friday, January 18, 2008 4:40 PM To: Mark Magpayo Cc: Dav