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
Attachment:
signature.asc
Description: This is a digitally signed message part.
