Re: Problem with ISO9660 and files stored on multiple extents

[Andrei Borzenkov]

16.02.2017 19:04, Vladimir 'phcoder' Serbinenko пишет:
> On Thu, Feb 16, 2017, 16:56 Carlo Caione <address@hidden> wrote:
> 
>> On Thu, Feb 16, 2017 at 4:54 PM, Vladimir 'phcoder' Serbinenko
>> <address@hidden> wrote:
>>>
>>>
>>> On Thu, Feb 16, 2017, 14:14 Carlo Caione <address@hidden> wrote:
>>>>
>>>> On Thu, Feb 16, 2017 at 2:09 PM, Vladimir 'phcoder' Serbinenko
>>>> <address@hidden> wrote:
>>>>>
>>>>>
>>>>> On Thu, Feb 16, 2017, 14:04 Carlo Caione <address@hidden> wrote:
>>>>>>
>>>>>> On Thu, Feb 16, 2017 at 12:37 PM, Carlo Caione <address@hidden>
>>>>>> wrote:
>>>>>>> On Thu, Feb 16, 2017 at 12:32 PM, Thomas Schmitt <
>> address@hidden>
>>>>>>> wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> Carlo Caione wrote:
>>>>>>>>>> I think that the problem
>>>>>>>>>> here is that endless.squash has been stored in two extents in
>> the
>>>>>>>>>> ISO9660 and GRUB doesn't deal fine with that (also according to
>>>>>>>>>> this
>>>>>>>>>> comment
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>> http://git.savannah.gnu.org/cgit/grub.git/tree/grub-core/fs/iso9660.c#n960
>>>>>>>>
>>>>>>>> Andrei Borzenkov wrote:
>>>>>>>>> This comment could be stale and misleading.
>>>>>>>>
>>>>>>>> The code of read_node() in iso9660.c looks ready for multi-extent
>>>>>>>> (aka
>>>>>>>> ISO
>>>>>>>> level 3).
>>>>>>>>
>>>>>>>> I have a very densely compressed test ISO for large file support
>>>>>>>>    http://scdbackup.webframe.org/large.iso.bz2
>>>>>>>> which bunzip2 inflates from 4.5 KiB to 4+ GiB.
>>>>>>>
>>>>>>> Yeah, I made some more tests and apparently the problem is not in
>> the
>>>>>>> ISO9660 module but in the SQUASH4 module.
>>>>>>> To be perfectly honest I have already a patch that solves my
>> problem
>>>>>>> but I'm having a hard time to understand WHY it solves the issue
>>>>>>> since
>>>>>>> I'm still not really familiar with squashfs (I casually found it
>>>>>>> during my debugging).
>>>>>>> Of course probably it is only masking a problem somewhere else.
>> Still
>>>>>>> digging.
>>>>>>>
>>>>>>> diff --git a/grub-core/fs/squash4.c b/grub-core/fs/squash4.c
>>>>>>> index b97b344..4fef813 100644
>>>>>>> --- a/grub-core/fs/squash4.c
>>>>>>> +++ b/grub-core/fs/squash4.c
>>>>>>> @@ -895,7 +895,7 @@ grub_squash_read_data (struct grub_squash_data
>>>>>>> *data,
>>>>>>>        break;
>>>>>>>      }
>>>>>>>
>>>>>>> -  if (fragment == 0xffffffff)
>>>>>>> +  if (fragment == 0xffffffff || fragment == 0)
>>>>>>>      return direct_read (data, ino, off, buf, len);
>>>>>>>
>>>>>>>    err = read_chunk (data, &frag, sizeof (frag),
>>>>>>
>>>>>> Hey Vladimir,
>>>>>> Any idea about this?
>>>>>
>>>>> How big is the file in question? What is the squash tools version?
>>>>
>>>> The squash image is 4564504576
>>>
>>> I mean the size of file you try to access
>>
>> In the squashfs image there is one single file of size 11470000128
>>
> Then it's possible that your patch is correct. I don't know why the format
> changes or what the 0 means in this field
> 

Looking at current squash tools git, 0 is valid fragment number. Any
chance we hit different file type here? Carlo, could you make your
squashfs image available?

>>
>> --
>> Carlo Caione  |  +39.340.80.30.096  |  Endless
>>
>