lz4hc compression in UBIFS?

[Konstantin Tokarev]

22.10.2013, 07:43, "Brent Taylor" <motobud at gmail.com>:
> On Mon, Oct 21, 2013 at 10:59 AM, Konstantin Tokarev <annulen at yandex.ru> wrote:
>
>>  04.10.2013, 07:09, "Brent Taylor" <motobud at gmail.com>:
>>>  Here is a patch based on linux-3.12-rc3.  I haven't performed any
>>>  performance testing UBIFS using lz4hc, but I can mount UBIFS volumes
>>>  and haven't seen any problems yet.  The only think I know that isn't
>>>  correct about the patch is the description for the Kconfig element for
>>>  select lz4hc as a compression option.  I only copied the description
>>>  from the lzo description.
>>  Hi Brent,
>>
>>  I'm testing your patch on my SH4 device. When I create new partition
>>  with lz4hc compressor, it works fine: I can copy file into it, and
>>  md5sums of original and copy match. However, after reboot I cannot
>>  read the file anymore:
>>
>>  UBIFS error (pid 1101): ubifs_decompress: cannot decompress 934 bytes, compressor lz4hc, error -22
>>  UBIFS error (pid 1101): read_block: bad data node (block 1, inode 65)
>>  UBIFS error (pid 1101): do_readpage: cannot read page 1 of inode 65, error -22
>>
>>  The same error appears if I use lz4hc-compressed ubifs image to flash rootfs
>>  (using patched mkfs.ubifs).
>>
>>  Decompression error occurs in lz4_uncompress() function (lib/lz4/lz4_decompress.c),
>>  on the line 101:
>>
>>  /* Error: offset create reference outside destination buffer */
>>  if (unlikely(ref < (BYTE *const) dest))
>>      goto _output_error;
>>
>>  Brent: are you able to read data from lz4hc volume on your device?
>>  Anyone: any ideas what may happen here?
>>
>>  --
>>  Regards,
>>  Konstantin
>
> Konstantin,
>    I haven't seen anything like that on my at91sam9m10g45-ek
> development board.  I haven't used a flash image from mkfs.ubifs yet.
> Is it possible the file system was not umounted cleanly before the
> reboot and UBIFS went through a recovery procedure?  Maybe something
> breaks with lz4hc when UBIFS does a recovery?  That's just a guess.

Could you save attached file on lz4hc volume, umount it and mount again?
I get aforementioned error when doing `cat set11.cfg`

-- 
Regards,
Konstantin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: set11.cfg
Type: application/octet-stream
Size: 169 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-mtd/attachments/20131022/19797e35/attachment-0001.obj>