Consistency problem with moving directories

[root]

Hello Mark,
I have seen now for the second time a problem with moving directories
inside a lessfs fs. I am using version 1.5.4.
I have a directory tree which contains a few hundred files including
subfolders. Now a t the level above, a new directory is created and
the existing tree is moved below that folder.

Example:
<some path>/<sourcedir>/R5.0
<some path>/<sourcedir>/R5.0.1
<some path>/<sourcedir>/R5.0.2

becomes:
<some path>/<sourcedir>/R5.0/R5.0
<some path>/<sourcedir>/R5.0/R5.0.1
<some path>/<sourcedir>/R5.0/R5.0.2

When restarting lessfs, there is no problem in lessfs.log, marked as
clean. However when doing a find on the mounted fs, I get the
following error messages:

find: WARNING: Hard link count is wrong for `<somepath>/<sourcedir>/
R5.0' (saw only snk=3 but we already saw 1 subdirectories): this may
be a bug in your file system driver. Automaticturning on find's -
noleaf option. Earlier results may have failed to include directories
that shouve been searched.

This problem is also replicated consistently to all 3 slave servers
(async. replication used).

So it looks like there is an important consistency issue here. Did you
happen to see this before? Can I help you in finding the problem?

Best Regards,
Hajo

[Mark Ruijter]

Hi Hajo,

I'll write a script to see if I can reproduce this.

Do you use BDB, hamsterdb or TC?

Verstuurd vanaf mijn iPhone

[Mark Ruijter]

Hi Hajo,

Would it be possible for you to write a little script that can reproduce
the problem?
When I try to test/simulate it, the problem does not occur.
The posix test suite did not find it either.

But that of course tells us only one thing, I am not testing it
properly. ;-)

Best Regards,

Mark

[root]

Hello Mark,

I have resolved this in the meantime by using the -noleaf option for
find in the first place.
Also, the problems on the slave servers have shown to be mainly
stability issues, part of the logfiles were not processed.

So this issue seems to be solved, unless you say that the st_nlink
value has to be different normally.

Best Regards,
Hajo

[Mark Ruijter]

Hi Hajo,

The problem must indeed be that st_nlink is not always updated correctly.
My problem is that I have not been able to reproduce this. ;-(
And this makes solving a rather simple issue difficult.

Best Regards,

Mark

[hajo]

Hello Mark,

this is an old post, but I fell across this issue again and found an easy way to reproduce the problem.
In the meantime, I am using lessfs-1.5.13, but the issue is still the same.

The problem can be reproduced by moving a directory one level up:

machine:/mnt/lessfs/test # ls -la
total 1
drwxr-xr-x 2 root root 4096 Nov 19 22:05 .
drwxr-xr-x 6 root root 4096 Nov 19 22:05 ..

starting with 2 links -ok

creating subdirs:

machine:/mnt/lessfs/test # mkdir sub
machine:/mnt/lessfs/test # ls -la
total 2
drwxr-xr-x 3 root root 4096 Nov 19 22:05 .
drwxr-xr-x 6 root root 4096 Nov 19 22:05 ..
drwxr-xr-x 2 root root 4096 Nov 19 22:05 sub
machine:/mnt/lessfs/test # cd sub
machine:/mnt/lessfs/test/sub # mkdir sub1
machine:/mnt/lessfs/test/sub # mkdir sub2
machine:/mnt/lessfs/test/sub # ls -la
total 2
drwxr-xr-x 4 root root 4096 Nov 19 22:06 .
drwxr-xr-x 3 root root 4096 Nov 19 22:05 ..
drwxr-xr-x 2 root root 4096 Nov 19 22:06 sub1
drwxr-xr-x 2 root root 4096 Nov 19 22:06 sub2

ok - the link count is 4 - which is okay for .
now we move one subdir up:

machine:/mnt/lessfs/test/sub # mv sub1 ..
machine:/mnt/lessfs/test/sub # ls -la
total 2
drwxr-xr-x 4 root root 4096 Nov 19 22:06 .
drwxr-xr-x 3 root root 4096 Nov 19 22:05 ..
drwxr-xr-x 2 root root 4096 Nov 19 22:06 sub2

As you can see, the link count of . is not decreasing, it stays at 4.
Also, the  link count for .. is not increasing by one, as it should be.

As I am still having stability problems with remote (watchdir-based) replication, I am trying to get all inconsistencies out in the first place.

The problem can be solved by copying the contents of the folder to outside of lessfs (used /tmp) and then copying them back in. Then the hard link count is corrected.

Would be great if you could look into this. I would be gladly doing preliminary patch testing.

Best Regards,
Hajo