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: Thu, 14 Feb 2013 12:34:59 -0600
Cc: xfs-oss <xfs@xxxxxxxxxxx>
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <511D12D5.8020203@xxxxxxxxxxxxxxx>
References: <511BC78B.6070205@xxxxxxxxxxxxxxx> <511BCB41.4060804@xxxxxxxxxxx> <511BCD11.20907@xxxxxxxxxxxxxxx> <511BCFB6.8000309@xxxxxxxxxxx> <511BD0FB.2070401@xxxxxxxxxxxxxxx> <511BD2D1.9010906@xxxxxxxxxxx> <511BD6ED.6030006@xxxxxxxxxxxxxxx> <511BEE8B.8000400@xxxxxxxxxxx> <511BF3B6.9040502@xxxxxxxxxxx> <511C07C6.9080003@xxxxxxxxxxx> <511C9E9C.8080200@xxxxxxxxxxxxxxx> <511CB0C3.9090507@xxxxxxxxxxxxxxx> <511CFC06.2030103@xxxxxxxxxxxxxxx> <511CFCBD.504@xxxxxxxxxxx> <511D12D5.8020203@xxxxxxxxxxxxxxx>
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
On 2/14/13 10:37 AM, Rémi Cailletaud wrote:
> Le 14/02/2013 16:03, Eric Sandeen a écrit :


<big snip>

>>> after adding the 4K device, growfs fail, and partition wont remount. I 
>>> tried a vgcfgrestore and vgreduce, but it does not mount : same error...
>>> XFS (dm-5): device supports 4096 byte sectors (not 512)
>> In that case I think you must not have actually (completely?) removed the 4k 
>> device.
> 
> That's it! After vgchange-ing un/available, lv mounts !
> 
> Following steps reproduce the "bug", considering we already have one pv on 
> /dev/sdc (512 sectors device) :
> 
> - create a virtual 4k scsi device and create a pv on it :
> # modprobe scsi_debug sector_size=4096 dev_size_mb=256
> # pvcreate /dev/sdd
> 
> - create a vg with both pv, and create an lv on sdc (I specified exact 
> extents count of sdc) :
> # vgcreate vgtest  /dev/sdc /dev/sdd
> # lvcreate -n lvtest -l 3759 vgtest
> 
> - mkfs, mount :
> # mkfs.xfs /dev/vgtest/lvtest
> # mount /dev/vgtest/lvtest /mnt/tmp
> 
> - the bad thing : lvextend and growfs (should not lvm or xfs check this 
> sector size stuff ?):

xfs does check, to some degree:

> # lvextend -l+40 /dev/vgtest/lvtest
> # xfs_growfs /mnt/tmp
> (fail with xfs_growfs: XFS_IOC_FSGROWFSDATA xfsctl failed)

^^^ see?  ;)  It could maybe be more explicit, but xfs is already in trouble by 
this point (before growfs, it still won't be remountable).  There is no 
opportunity for xfs to catch this damage before it's done.

Yes, I think lvm should check before allowing the change.

> 
> - the scary part :
> # umount /mnt/tmp
> # mount /dev/vgtest/lvtest /mnt/tmp
> mount: function not implemented
> # tail -1 /var/log/messages
> Feb 14 16:41:52 hamaika kernel: [  481.055422] XFS (dm-5): device supports 
> 4096 byte sectors (not 512)
> 
> - the huge relief (restoring *before* lvextend) :
> # vgcfgrestore -f /etc/lvm/archive/vgtest_00029-84595486.vg vgtest
> # vgchange -a n vgtest
> # vgchange -a y vgtest
> # mount /dev/vgtest/lvtest /mnt/tmp
> 
> yippee, my datas are back !!

cool.

> 
> Should I submit a bug report ? On LVM, XFS, both ?

I don't know what xfs could have done here.  Even if you didn't growfs, by the 
time you did lvextend xfs wouldn't have been able to remount.  I think it's up 
to lvm to protect the user from this, personally, so a bug report there seems 
warranted.

> However, a great thanks for your help... I learned some stuff about lvm and 
> xfs today ;)

You're welcome, very glad you got it back.
Thank my employer Red Hat for paying me to work on this stuff, too ;)

-Eric

> Cheers,
> 
> rémi
> 
>>
>> I think you'll need to seek help from LVM people in order to proceed...  I'm 
>> sure it's possible to safely and completely remove the newly added space, 
>> but I don't know how.
>>
>> -Eric
>>
>>
> 
> 

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