Date: Tue, 11 Nov 2008 10:04:35 +0100 From: Attila Nagy <bra@fsn.hu> To: Peter Jeremy <peterjeremy@optushome.com.au> Cc: freebsd-fs@freebsd.org Subject: Re: Different inodes Message-ID: <49194AA3.2090208@fsn.hu> In-Reply-To: <20081110190151.GI51239@server.vk2pj.dyndns.org> References: <49185518.2020600@fsn.hu> <20081110190151.GI51239@server.vk2pj.dyndns.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Peter Jeremy wrote: > On 2008-Nov-10 16:36:56 +0100, Attila Nagy <bra@fsn.hu> wrote: > >> 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 >> > > 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. > 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 -li /20081021/usr/local/lib/python2.5/config/libpython2.5.so 3817980 lrwxr-xr-x 1 root wheel 30 Oct 29 09:40 /20081021/usr/local/lib/python2.5/config/libpython2.5.so -> /usr/local/lib/libpython2.5.so # /bin/ls -li /usr/local/lib/libpython2.5.so 73739 lrwxr-xr-x 1 root wheel 17 Oct 18 09:23 /usr/local/lib/libpython2.5.so -> libpython2.5.so.1 # /bin/ls -li /usr/local/lib/libpython2.5.so.1 73738 -r-xr-xr-x 1 root wheel 1364800 Oct 18 09:23 /usr/local/lib/libpython2.5.so.1 # /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 > >> 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? >> > > This shouldn't affect the above. > 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?49194AA3.2090208>