Peter Jeremy wrote:[color=blue]
> On 2008-Nov-10 16:36:56 +0100, Attila Nagy <bra@fsn.hu> wrote:
>[color=green]
>> I don't quite get this:
>>
>> ls -i /20081021/usr/local/lib/python2.5/config/
>> 3817938 .svn 3817976 Setup.local 3817978 libpython2.5.a
>> 3817979 Makefile 3817975 config.c 3817980 libpython2.5.so
>> 3817973 Setup 3817977 config.c.in 3817982 makesetup
>> 3817974 Setup.config 3817981 install-sh 3817983 python.o
>>
>> ls -i /20081021/usr/local/lib/python2.5/config/libpython2.5.*
>> 3817978 /20081021/usr/local/lib/python2.5/config/libpython2.5.a
>> 73738 /20081021/usr/local/lib/python2.5/config/libpython2.5.so
>>[/color]
>
> I can't reproduce it here on 7-stable. Note that libpython2.5.so
> is a symlink so it seems likely that one of your ls commands is
> de-referencing the symlink and the other isn't - though I don't
> know how this is being done.
>
> Can you confirm that you are using /bin/ls (not an alias or some
> alternate variant). You might also verify that you get the same
> result using /bin/sh as a shell.
>[/color]
You are right, it's a symlink. What I run is a 7-STABLE on amd64 built
at Wed May 28 17:02:56 CEST 2008.
With /bin/sh as my shell:
# /bin/ls -i /20081021/usr/local/lib/python2.5/config/libpython2.5.so
73738 /20081021/usr/local/lib/python2.5/config/libpython2.5.so

# /bin/ls -i /20081021/usr/local/lib/python2.5/config
3817938 .svn 3817973 Setup 3817976 Setup.local 3817977
config.c.in 3817978 libpython2.5.a 3817982 makesetup
3817979 Makefile 3817974 Setup.config 3817975 config.c 3817981
install-sh 3817980 libpython2.5.so 3817983 python.o
[color=blue]
>[color=green]
>> The modification consists of changed arc4randoms in
>> sys/ufs/ffs/ffs_alloc.c and ffs_vfsops.c to a constant value, but I
>> don't think it can be the cause. Could it be?
>>[/color]
>
> This shouldn't affect the above.
>[/color]
Well, the full story is the following:
- I have two NFS servers per site, which act as redundant file servers
(the above is on one of those machines)
- I run a modified kernel on these (see above) to be able to achieve
inode consistency between the machines (so in case of failover, the
clients won't crash with stale filehandles)
- the shares are read only (to the NFS clients)
- I update the content from subversion by running an "svn up" on both
pairs simultaneously and with the above patch, the files' inodes
remained consistent
- after the svn up I did an ls -Ri on the working copy on both machines,
and made a diff from them. If the diff was empty, the inodes were right,
if it wasn't, then there was a problem. Until now, everything was right.
- what has changed now is two fold:
1. the content has grown so large, that an svn up from the working
copy's root ran too long, so I have switched to the method of comparing
the revision of the working copy, and the svn repo's head, made a diff
summary and only updated (deep in the tree) what's needed
2. for the same cause, I have switched from ls -Ri to printing each
modified file's inode number

It seems that symlinks are inconsistent then listing them with "ls -i"
directly, but with "ls -Ri" shows no errors. Also, I didn't faced any
problems so far when switching NFS servers.

So what I see now is that everything is OK (for me, the inodes are in
sync), the problem is that I must check for the symlink's inode number
and must not let ls to resolve that back to the outer filesystem, which
is of course differs on the machines.

Problem solved for me, the question is whether the above inner working
of ls is a misbehaviour, or is it just normal.
_______________________________________________
[email]freebsd-fs@freebsd.org[/email] mailing list
[url]http://lists.freebsd.org/mailman/listinfo/freebsd-fs[/url]
To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org"