On 09/17/2014 04:22 PM, Duncan wrote:
> Austin S Hemmelgarn posted on Wed, 17 Sep 2014 07:23:46 -0400 as
> excerpted:
>
>> I've also discovered, when trying to use btrfs restore to copy out the
>> data to a different system, that 3.14.1 restore apparently chokes on
>> filesystem that have lzo compression turned on. It's reporting errors
>> trying to inflate compressed files, and I know for a fact that none of
>> those files were even open, let alone being written to, when the system
>> crashed. I don't know if this is a known bug or even if it is still the
>> case with btrfs-progs 3.16, but I figured I'd comment about it because I
>> haven't seen anything about it anywhere.
>
> FWIW that's a known and recently patched issue. If you're still seeing
> issues with it with btrfs-progs 3.16, report it, but 3.14.1 almost
> certainly wouldn't have had the fix. (This is one related patch turned
> up by a quick search; there may be others.)
>
> * commit 93ebec96f2ae1d3276ebe89e2d6188f9b46692fb
> | Author: Vincent Stehlé <vincent.ste...@laposte.net>
> | Date: Wed Jun 18 18:51:19 2014 +0200
> |
> | btrfs-progs: restore: check lzo compress length
> |
> | When things go wrong for lzo-compressed btrfs, feeding
> | lzo1x_decompress_safe() with corrupt data during restore
> | can lead to crashes. Reduce the risk by adding
> | a check on the input length.
> |
> | Signed-off-by: Vincent Stehlé <vincent.ste...@laposte.net>
> | Signed-off-by: David Sterba <dste...@suse.cz>
> |
> | cmds-restore.c | 6 ++++++
> | 1 file changed, 6 insertions(+)
>
Yeah, 3.16 seems fine, I just hadn't updated my recovery environment
yet. Ironically, I did some performance testing afterwards, and
realized that using any compression was actually slowing down my system
(my disk appears to be faster than my RAM, which is really sad, even for
a laptop).
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
