| To: | xfs@xxxxxxxxxxx |
|---|---|
| Subject: | Re: Virtual Block device resize corrupts XFS |
| From: | Spelic <spelic@xxxxxxxxxxxxx> |
| Date: | Mon, 17 Nov 2014 00:07:52 +0100 |
| Delivered-to: | xfs@xxxxxxxxxxx |
| In-reply-to: | <20141116223630.GH23575@dastard> |
| References: | <5468FC60.10901@xxxxxx> <20141116223630.GH23575@dastard> |
| User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 |
On 16/11/2014 23:36, Dave Chinner wrote: On Sun, Nov 16, 2014 at 08:34:56PM +0100, Markus Rhonheimer wrote:A few days ago I wanted to increase the size of the block device, but accidently decreased it by 1 TB (from 7 to 6). I found out about it and immediately increased the size of the drive to 8 TB afterward.If that was a normal LVM block device, there would have been no trouble. But you're using something special, unusual and completely untested, so the most likely outcome is going to be that you still have a pile of broken bits. Not true! Depends on the allocation strategy chosen for LVM and the position of free space. Probably recovering LVM conf from backups (which usually is automatically made) can recover the exact LVM layout of prior to the shrink. |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: Virtual Block device resize corrupts XFS, Dave Chinner |
|---|---|
| Next by Date: | Re: Virtual Block device resize corrupts XFS, Spelic |
| Previous by Thread: | Re: Virtual Block device resize corrupts XFS, Dave Chinner |
| Next by Thread: | Re: Virtual Block device resize corrupts XFS, Spelic |
| Indexes: | [Date] [Thread] [Top] [All Lists] |