[Filesystems-devel] Bug#788185: squashfs: Last few kB stored as nulls.

Andreas Krüger andreas.krueger at famsik.de
Sat Jun 13 13:29:35 UTC 2015


Hello,

in the meantime, I tried to reproduce the bug with an artificial
setup, but couldn't.

With one of my regular backups, again one big file wasn't stored in
the squashfs correctly.

This time, I investigated further, by running both files through od -c
and comparing via diff -u.  Not very efficient, needs quite a few GB
of RAM, but works:

--- /tmp/should 2015-06-13 09:14:28.713323748 +0200
+++ /tmp/is     2015-06-13 09:14:33.625302914 +0200
@@ -156571783,1800 +156571783,4 @@
 24533777760   6   .   3   2   -   4   3   1   .   2   9   .   2   .   e   l
 24534000000  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0
 *
-24535530000 336   o 177 303 334 257 215   # 227 367   9 314 377 344   C  \b
[many lines starting with "-" and showing data from the "should" file omitted]
-24535620000   l   =   c   r   o   n       r   e   s   =   s   u   c   c   e
-24535620020   s   s   '  \n  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0
-24535620040  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0
-*
 24536000000

So what I'm seeing here is:

* The squashfs copy and the original file agree for most of its
  content.
* The lengths of the two agree.
* The last few kByte of the squashfs copy does not show the content it
  should, but nulls instead.

As mentioned before, I'm using

mksquashfs inroot out.squashfs -always-use-fragments -processors 2

My guess is that my combination of "-always-use-fragments" and
"-processors 2" and many files and a few really big files triggers a
race condition in the mksquashfs code.

Regards,
and thank you for providing fine software,

Andreas

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/filesystems-devel/attachments/20150613/af987adc/attachment.sig>


More information about the Filesystems-devel mailing list