Hi,
Well in fact I cannot find where the problem is coming from. I am also
not sure if tar or nilfs2 is causing it. Actually I am using tar -xPpf
as this will create symlinks directly without passing through the
sometimes failing delaying mechanism. Please tell me if you want any
further information.
Bye,
David Arendt
David Arendt wrote:
> Hi,
>
> I am still inverstigating here, I created tar files with 100000 symbolic
> links, and they extracted without any problem. Only a tar of my whole
> nfsroot directory fails to extract properly to nilfs2, but does
> correctly to ext4.I wouldn't mind giving you that files, but it are
> 3.3gbytes. What is also curious is that the stat calls in tar seem to
> return the right inode number, but at the check, it is 0. I am currently
> adding debugging printfs to tar in hope to catch the problem this way.
>
> Bye,
> David Arendt
>
> Ryusuke Konishi wrote:
>
>> Hi David,
>> On Sun, 01 Feb 2009 00:21:23 +0100, David Arendt wrote:
>>
>>
>>> Hi,
>>>
>>> I narrowed the problem down. I'm not sure if it's a problem of tar or of
>>> nifls2.
>>>
>>> Tar handles symbolic links this way:
>>>
>>> during extraction: if symbolic link and absolute path create a 0 byte
>>> file and record link and stat information
>>>
>>> after extraction: for every symbolic link verify that actual
>>> st_dev,st_ino and st_mtime are the same as on creation of the 0 byte
>>> file, and only then create the link
>>>
>>> for some 0 byte files st_ino is different between the first and the
>>> second stat of the 0 byte file. As I don't know the nilfs2 internal
>>> behavior, so could you please tell me if this is the normal behavior of
>>> nilfs2 or if there is something strange with this ? If it's the normal
>>> behavior, maybe I should file a bug for tar ?
>>>
>>>
>> This behavior seems unusual.
>> Could you send me a small tar file which can reproduce the problem ?
>>
>>
>>
>>> This patch for tar 1.21 solves the symlink problem but I don't know if
>>> the problem is to be solved on the tar end or on the nilfs2 end.
>>>
>>>
>>> diff -Naur tar-1.21/src/extract.c tar-1.21.new/src/extract.c
>>> --- tar-1.21/src/extract.c 2008-10-30 15:10:28.000000000 +0100
>>> +++ tar-1.21.new/src/extract.c 2009-01-31 23:32:03.000000000 +0100
>>> @@ -1267,7 +1267,6 @@
>>> removed by a later extraction. */
>>> if (lstat (source, &st) == 0
>>> && st.st_dev == ds->dev
>>> - && st.st_ino == ds->ino
>>> && timespec_cmp (get_stat_mtime (&st), ds->mtime) == 0)
>>> {
>>> /* Unlink the placeholder, then create a hard link if possible,
>>>
>>>
>>> What do you think ?
>>>
>>>
>> I think this comparision is appropriate to confirm identity of the
>> placeholder file.
>>
>> I have no idea why inode number had changed as you reported.
>> Symbolic links of nilfs2 are simply implemented.
>>
>> If it's unique to nilfs2, you may hit some sort of timing issue.
>> I think a sample tar file would be helpful to figure out what's
>> happening.
>>
>> Regards,
>> Ryusuke Konishi
>>
>>
>>
>>> David Arendt wrote:
>>>
>>>
>>>> Hi,
>>>>
>>>> After using nilfs2 for half a year now on data partitions without any
>>>> problems, I wanted to try it for the root partition. This way I
>>>> discovered a silent random symbolic link corruption problem.
>>>>
>>>> Versions:
>>>>
>>>> latest nilfs2 git module
>>>> kernel 2.6.28.2
>>>> tar 1.20
>>>>
>>>> Step to reproduce it:
>>>>
>>>> tar -xpf zz1.tar (where zz1.tar is a tar file containing many symbolic
>>>> links (in my case a directory containing 2 root filesystems for remote
>>>> booting)
>>>>
>>>> On untar some symbolic links are missing and 0 byte files are existing
>>>> instead.
>>>>
>>>> I repeated the test 3 times on a freshly formated nilfs2 partition and
>>>> always had other links missing.
>>>>
>>>> I am currently trying to bzip2 the big tar file and untar this one in
>>>> order to verify if there are no timing issues and will report back when
>>>> this test is finished.
>>>>
>>>> Could you please look into this ?
>>>>
>>>> Thanks in advance
>>>> Bye,
>>>> David Arendt
>>>>
>>>> _______________________________________________
>>>> users mailing list
>>>> [email protected]
>>>> https://www.nilfs.org/mailman/listinfo/users
>>>>
>>>>
>>>>
>>> _______________________________________________
>>> users mailing list
>>> [email protected]
>>> https://www.nilfs.org/mailman/listinfo/users
>>>
>>>
>> _______________________________________________
>> users mailing list
>> [email protected]
>> https://www.nilfs.org/mailman/listinfo/users
>>
>>
>
> _______________________________________________
> users mailing list
> [email protected]
> https://www.nilfs.org/mailman/listinfo/users
>
_______________________________________________
users mailing list
[email protected]
https://www.nilfs.org/mailman/listinfo/users
