Hello Guy,

Am Donnerstag, 4. September 2014, 11:00:55 schrieb Gui Hecheng:
> On Mon, 2014-09-01 at 15:25 +0000, Zooko Wilcox-OHearn wrote:
> > I'm more than happy to try out patches and even focus my own brain on
> > diagnosing it, if I can. I'm hoping to regain access to some of my
> > files on my btrfs partition, and also I would enjoy helping get this
> > improved. :-)
> > 
> > So if you want me to try an experiment, just email me. Unfortunately I
> > can't just give you a copy of the partition, since it has confidential
> > information on it.
> > 
> > Regards,
> > 
> > Zooko
> 
> Hi Zooko, Marc,
> 
> Firstly, thanks for your backtrace info, Marc.
> Sorry to reply late, since I'm offline these days.
> For the restore problem, I'm sure that the lzo decompress routine lacks
> the ability to handle some specific extent pattern.
> 
> Here is my test result:
> I'm using a specific file for test
> /usr/lib/modules/$(uname -r)/kernel/net/irda/irda.ko.
> You can get it easily on your own box.
> 
> 	# mkfs -t btrfs <dev>
> 	# mount -o compress-force=lzo <dev> <mnt>
> 	# cp irda.ko <mnt>
> 	# umount <dev>
> 	# btrfs restore -v <dev> <restore_dir>
> report:
> 	# bad compress length
> 	# failed to inflate

uh, that's really odd. I don't use force compress, but I guess it will also 
happen with non-forced one if the file is big enough.

> btrfs-progs version: v3.16.x
> 
> With the same file under no-compress & zlib-compress,
> the restore will output a correct copy of irda.ko.
> 
> I'm not sure whether the problem above has something to do with your
> problem. Hope that the messages above are helpful.

I also get lot's of "bad compress length", so it might be indeed related.

I'm not a programmer, but is it possible that we are just skipping the lzo 
header (magic + header len + rest of header)?

Thanks,

Marc