Hello Guy, Am Donnerstag, 4. September 2014, 11:50:14 schrieb Marc Dietrich: > Am Donnerstag, 4. September 2014, 11:00:55 schrieb Gui Hecheng: > > 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)?
I'm able to reproduce it. Any improved insight into this problem? Marc
signature.asc
Description: This is a digitally signed message part.
