From: Eric Sandeen <sandeen@sandeen.net>
To: "Rémi Cailletaud" <remi.cailletaud@3sr-grenoble.fr>
Cc: xfs-oss <xfs@oss.sgi.com>
Subject: Re: problem after growing
Date: Thu, 14 Feb 2013 12:34:59 -0600 [thread overview]
Message-ID: <511D2E53.3070403@sandeen.net> (raw)
In-Reply-To: <511D12D5.8020203@3sr-grenoble.fr>
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
>>
>>
>
>
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
prev parent reply other threads:[~2013-02-14 18:35 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-13 17:04 problem after growing Rémi Cailletaud
2013-02-13 17:20 ` Eric Sandeen
2013-02-13 17:27 ` Rémi Cailletaud
2013-02-13 17:39 ` Eric Sandeen
2013-02-13 17:44 ` Rémi Cailletaud
2013-02-13 17:52 ` Eric Sandeen
2013-02-13 18:09 ` Rémi Cailletaud
2013-02-13 19:50 ` Eric Sandeen
2013-02-13 20:12 ` Eric Sandeen
2013-02-13 21:18 ` Rémi Cailletaud
2013-02-13 21:38 ` Eric Sandeen
2013-02-14 8:21 ` Rémi Cailletaud
2013-02-14 9:39 ` Rémi Cailletaud
[not found] ` <511CFC06.2030103@3sr-grenoble.fr>
[not found] ` <511CFCBD.504@sandeen.net>
2013-02-14 16:37 ` Rémi Cailletaud
2013-02-14 18:34 ` Eric Sandeen [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=511D2E53.3070403@sandeen.net \
--to=sandeen@sandeen.net \
--cc=remi.cailletaud@3sr-grenoble.fr \
--cc=xfs@oss.sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox