xfs
[Top] [All Lists]

Re: problem after growing

To: Eric Sandeen <sandeen@xxxxxxxxxxx>
Subject: Re: problem after growing
From: Rémi Cailletaud <remi.cailletaud@xxxxxxxxxxxxxxx>
Date: Wed, 13 Feb 2013 18:44:27 +0100
Cc: xfs-oss <xfs@xxxxxxxxxxx>
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <511BCFB6.8000309@xxxxxxxxxxx>
References: <511BC78B.6070205@xxxxxxxxxxxxxxx> <511BCB41.4060804@xxxxxxxxxxx> <511BCD11.20907@xxxxxxxxxxxxxxx> <511BCFB6.8000309@xxxxxxxxxxx>
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.12) Gecko/20130116 Icedove/10.0.12
Le 13/02/2013 18:39, Eric Sandeen a écrit :
On 2/13/13 11:27 AM, Rémi Cailletaud wrote:
Le 13/02/2013 18:20, Eric Sandeen a écrit :
On 2/13/13 11:04 AM, Rémi Cailletaud wrote:
Hi,

I face a strange and scary issue. I just grow a xfs filesystem (44To), and no 
way to mount it anymore :
XFS: device supports only 4096 byte sectors (not 512)
Did you expand an LV made of 512-sector physical devices by adding 4k-sector 
physical devices?
The three devices are ARECA 1880 card, but the last one was added later, and I 
never check for sector physical configuration on card configuration.
But yes, running fdisk, it seems that sda and sdb are 512, and sdc is 4k... :(

that's probably not something we anticipate or check for....

What sector size(s) are the actual lowest level disks under all the lvm pieces?
(re-cc'ing xfs list)

What command to run to get this info ?
IIRC,

# blockdev --getpbsz --getss  /dev/sda

to print the physical&  logical sector size

You can also look at i.e.:
/sys/block/sda/queue/hw_sector_size
/sys/block/sda/queue/physical_block_size
/sys/block/sda/queue/logical_block_size
ouch... nice guess :
#  blockdev --getpbsz --getss  /dev/sda
512
512
#  blockdev --getpbsz --getss  /dev/sdb
512
512
#  blockdev --getpbsz --getss  /dev/sdc
4096
4096


I wonder what the recovery steps would be here.  I wouldn't do anything yet; I 
wish you hadn't already cleared the log, but oh well.

I tried a xfs_repair -L (as mentionned by xfs_check), but it early failed as show on my first post...
So you grew it, that all worked ok, you were able to copy new data into the new 
space, you unmounted it, but now it won't mount, correct?
I never was able to copy data to new space. I had an input/output error just after growing.
may pmove-ing extents on 4k device on a 512k device be a solution ?

rémi

-Eric



rémi


-Eric

# xfs_check /dev/vg0/tomo-201111
ERROR: The filesystem has valuable metadata changes in a log which needs to
be replayed.  Mount the filesystem to replay the log, and unmount it before
re-running xfs_check.  If you are unable to mount the filesystem, then use
the xfs_repair -L option to destroy the log and attempt a repair.
Note that destroying the log may cause corruption -- please attempt a mount
of the filesystem before doing this.

# xfs_repair -L /dev/vg0/tomo-201111
xfs_repair: warning - cannot set blocksize 512 on block device 
/dev/vg0/tomo-201111: Argument invalide
Phase 1 - find and verify superblock...
superblock read failed, offset 1099511623680, size 2048, ag 1, rval -1

fatal error -- Invalid argument

Conf is as follow :

LVM : 3pv - 1vg

the lv containing the xfs system is on several extents :

    tomo-201111 vg0  -wi-ao    1 linear  15,34t /dev/sda:5276160-9298322
    tomo-201111 vg0  -wi-ao    1 linear  18,66t /dev/sdb:0-4890732
    tomo-201111 vg0  -wi-ao    1 linear   8,81t /dev/sdb:6987885-9298322
    tomo-201111 vg0  -wi-ao    1 linear   1,19t /dev/sdc:2883584-3194585

before growing fs, I lvextend the vg, and a new extents on /dev/sdc was used. I 
cant think it caused this issue... I saw there can be problem with underlying 
device (an ARECA 1880). With xfs_db, I found this strange :
   "logsectsize = 0"

# xfs_db -c "sb 0" -c "p" /dev/vg0/tomo-201111
magicnum = 0x58465342
blocksize = 4096
dblocks = 10468982745
rblocks = 0
rextents = 0
uuid = 09793bea-952b-44fa-be71-02f59e69b41b
logstart = 1342177284
rootino = 128
rbmino = 129
rsumino = 130
rextsize = 1
agblocks = 268435455
agcount = 39
rbmblocks = 0
logblocks = 521728
versionnum = 0xb4b4
sectsize = 512
inodesize = 256
inopblock = 16
fname = "\000\000\000\000\000\000\000\000\000\000\000\000"
blocklog = 12
sectlog = 9
inodelog = 8
inopblog = 4
agblklog = 28
rextslog = 0
inprogress = 0
imax_pct = 5
icount = 6233280
ifree = 26
fdblocks = 1218766953
frextents = 0
uquotino = 0
gquotino = 0
qflags = 0
flags = 0
shared_vn = 0
inoalignmt = 2
unit = 0
width = 0
dirblklog = 0
logsectlog = 0
logsectsize = 0
logsunit = 1
features2 = 0xa
bad_features2 = 0xa


Any idea ?

Cheers,
rémi

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


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



--
Rémi Cailletaud - IE CNRS
3SR - Laboratoire Sols, Solides, Structures - Risques
BP53, 38041 Grenoble CEDEX 0
FRANCE
remi.cailletaud@xxxxxxxxxxxxxxx
Tél: +33 (0)4 76 82 52 78
Fax: +33 (0)4 76 82 70 43



<Prev in Thread] Current Thread [Next in Thread>