problem after growing

[Rémi Cailletaud]

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?

What command to run to get this info ?

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
>


-- 
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