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
_______________________________________________
xfs mailing list
xfs@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/xfs
