xfs
[Top] [All Lists]

Re: problem after growing

To: Rémi Cailletaud <remi.cailletaud@xxxxxxxxxxxxxxx>
Subject: Re: problem after growing
From: Eric Sandeen <sandeen@xxxxxxxxxxx>
Date: Wed, 13 Feb 2013 11:20:01 -0600
Cc: xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <511BC78B.6070205@xxxxxxxxxxxxxxx>
References: <511BC78B.6070205@xxxxxxxxxxxxxxx>
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
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?

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?

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

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