Re: problem after growing

["Rémi Cailletaud" <remi.cailletaud@3sr-grenoble.fr>]

Le 14/02/2013 09:21, Rémi Cailletaud a écrit :
> Le 13/02/2013 22:38, Eric Sandeen a écrit :
>> On 2/13/13 2:12 PM, Eric Sandeen wrote:
>>> On 2/13/13 1:50 PM, Eric Sandeen wrote:
>>>> On 2/13/13 12:09 PM, Rémi Cailletaud wrote:
>>>>> Le 13/02/2013 18:52, Eric Sandeen a écrit :
>>>> <snip>
>>>>
>>>>>> Did the filesystem grow actually work?
>>>>>>
>>>>>> # xfs_db -c "sb 0" -c "p" /dev/vg0/tomo-201111
>>>>>> magicnum = 0x58465342
>>>>>> blocksize = 4096
>>>>>> dblocks = 10468982745
>>>>>>
>>>>>> That looks like it's (still?) a 38TiB/42TB filesystem, with:
>>>>>>
>>>>>> sectsize = 512
>>>>>>
>>>>>> 512 sectors.
>>>>>>
>>>>>> How big was it before you tried to grow it, and how much did you 
>>>>>> try to grow it by?  Maybe the size never changed.
>>>>> Was 39, growing to 44. Testdisk says 48 TB / 44 TiB... There is 
>>>>> some chance that it was never really growed.
>>>>>> At mount time it tries to set the sector size of the device; its' 
>>>>>> a hard-4k device, so setting it to 512 fails.
>>>>>>
>>>>>> This may be as much of an LVM issue as anything; how do you get 
>>>>>> the LVM device back to something with 512-byte logical sectors?  
>>>>>> I have no idea...
>>>>>>
>>>>>> *if* the fs didn't actually grow, and if the new 4k-sector space 
>>>>>> is not used by the filesystem, and if you can somehow remove that 
>>>>>> new space from the device and set the LV back to 512 sectors, you 
>>>>>> might be in good shape.
>>>>> I dont either know how to see nor set LV sector size.  It's 100% 
>>>>> sure that anything was copied on 4k sector size, and pretty sure 
>>>>> that the fs did not really grow.
>>>> I think the same blockdev command will tell you.
>>>>
>>>>
>>>>>> Proceed with extreme caution here, I wouldn't start just trying 
>>>>>> random things unless you have some other way to get your data 
>>>>>> back (backups?).  I'd check with LVM folks as well, and maybe see 
>>>>>> if dchinner or the sgi folks have other suggestions.
>>>>> Sigh... No backup (44To is too large for us...) ! I'm running a 
>>>>> testdisk recover, but I'm not very confident about success...
>>>>> Thanks to deeper investigate this...
>>>>>> First let's find out if the filesystem actually thinks it's 
>>>>>> living on the new space.
>>>>> What is the way to make it talk about that ?
>>>> well, you have 10468982745 4k blocks in your filesystem, so 
>>>> 42880953323520 bytes of xfs filesystem.
>>>>
>>>> Look at your lvm layout, does that extend into the new disk space 
>>>> or is it confined to the original disk space?
> Seems it does not : lvm map shows 48378494844928 bytes, 1304432738304 
> on the 4K device.
>
>>> lvm folks I talk to say that if you remove the 4k device from the 
>>> lvm volume it should switch back to 512 sectors.
>>>
>>> so if you can can convince yourself that 42880953323520 bytes does 
>>> not cross into the newly added disk space, just remove it again, and 
>>> everything should be happy.
>>>
>>> Unless your rash decision to start running "testdisk" made things 
>>> worse ;)
>> I tested this.  I had a PV on a normal 512 device, then used 
>> scsi_debug to create a 4k device.
>>
>> I created an LV on the 512 device&  mounted it, then added the 4k 
>> device as you did.  growfs failed immediately, and the device won't 
>> remount due to the sector size change.
>>
>> I verified that removing the 4k device from the LV changes the LV 
>> back to a 512 sector size.
>>
>> However, I'm not 100% sure how to remove just the 4K PV; when I did 
>> it, I did something wrong and it reduced the size of my LV to the 
>> point where it corrupted the filesystem.  :)  Perhaps you are a 
>> better lvm admin than I am.
> How did you remove the pv ? I would tend to use vgreduce, but I'm a 
> bit (a lot, in fact) scary about fs corruption. That's why I was 
> wondering about pvmove'ing extents on a 512K device
Or may a vgcfgrestore be safer ? Should I ask lvm folks ?

rémi

>
> rémi
>
>> But in any case - if you know how to safely remove ONLY the 4k device 
>> from the LV, you should be in good shape again.
>>
>> -Eric
>>
>>
>>
>
>


-- 
Rémi Cailletaud - IE CNRS
3SR - Laboratoire Sols, Solides, Structures - Risques
BP53, 38041 Grenoble CEDEX 0
FRANCE
remi.cailletaud@3sr-grenoble.fr
Tél: +33 (0)4 76 82 52 78
Fax: +33 (0)4 76 82 70 43



_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs