From: "Rémi Cailletaud" <remi.cailletaud@3sr-grenoble.fr>
To: Eric Sandeen <sandeen@sandeen.net>
Cc: xfs-oss <xfs@oss.sgi.com>
Subject: Re: problem after growing
Date: Wed, 13 Feb 2013 22:18:59 +0100 [thread overview]
Message-ID: <69fd0a0f-1574-4013-8efb-a408f59ea28a@email.android.com> (raw)
In-Reply-To: <511BF3B6.9040502@sandeen.net>
Eric Sandeen <sandeen@sandeen.net> a écrit :
>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?
>
>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.
>
Ok, I'll check that tomorrow and try to remove added space if my fs does not live on...
>Unless your rash decision to start running "testdisk" made things worse
>;)
It's only analyse, it does not modify anything... it should not have any effect...
Thx again,
rémi
>-Eric
>
>> -Eric
>>
>>> Thanks again for your help !
>>>
>>> rémi
>>>
>>>> -Eric
>>>>
>>>>> rémi
>
>_______________________________________________
>xfs mailing list
>xfs@oss.sgi.com
>http://oss.sgi.com/mailman/listinfo/xfs
--
Envoyé de mon téléphone Android avec K-9 Mail. Excusez la brièveté.
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2013-02-13 21:21 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 [this message]
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
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=69fd0a0f-1574-4013-8efb-a408f59ea28a@email.android.com \
--to=remi.cailletaud@3sr-grenoble.fr \
--cc=sandeen@sandeen.net \
--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