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:
>>> 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
(re-cc'ing xfs list)
> What command to run to get this info ?
# blockdev --getpbsz --getss /dev/sda
to print the physical & logical sector size
You can also look at i.e.:
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.
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?
>>> # 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 ?
>> xfs mailing list