Re: Problem with unmountable filesystem.

[Duncan <1i5t5.duncan@cox.net>]

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.stehle@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.stehle@laposte.net>
|     Signed-off-by: David Sterba <dsterba@suse.cz>
|
|  cmds-restore.c | 6 ++++++
|  1 file changed, 6 insertions(+)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman