Re: fs corruption report

[Marc Dietrich <marvin24@gmx.de>]

[-- Attachment #1: Type: text/plain, Size: 1520 bytes --]

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 490 bytes --]