problem after growing

Wed Feb 13 11:44:27 CST 2013

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 at oss.sgi.com
>>> http://oss.sgi.com/mailman/listinfo/xfs
>>>
>>
> _______________________________________________
> xfs mailing list
> xfs at oss.sgi.com
> 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 at 3sr-grenoble.fr
Tél: +33 (0)4 76 82 52 78
Fax: +33 (0)4 76 82 70 43