GNU bug report logs - #21715
feat req: an option to skip directory inode comparison

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 21715 in the body.
You can then email your comments to 21715 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Aaron Davies <aaron.davies <at> gmail.com>
To: bug-diffutils <at> gnu.org
Subject: feat req: an option to skip directory inode comparison
Date: Mon, 19 Oct 2015 22:27:28 -0400

i have a situation where diff -r of two directories fails to report differences that diff of two files in those directories shows

i haven't dug into the code yet, but the directories involved are on an NFS mount of a netapp filer, one is the copy-on-write snapshot counterpart of the other, they show up as the same filesystem, and are the same inode

so my guess is that there's something in the recursive traversal that says that any two directories that are on the same fs and are the same inode must have identical descendent contents and can be skipped completely

this fs probably violates POSIX by doing this, but there's no easy way around it[1], so it would be very useful if diff had a command-line option to turn that optimization off

i've heard anecdotal reports of other filesystems that cause the same problem

here's a sample session:

$ mkdir foo
$ echo baz >foo/bar
$ # wait until the next snapshot is created
$ echo quux >foo/bar
$ diff -r .snapshot/nightly.0/foo foo
$ diff .snapshot/nightly.0/foo/bar foo/bar
1c1
< baz
---
> quux
$ stat -c %i .snapshot/nightly.0/foo foo
69403847
69403847
$ 
-- 
Aaron Davies
aaron.davies <at> gmail.com

[1] when i ran into this, i ended up using something like diff <(find .snapshot/nightly.0/foo -type f|sort|xargs cat) <(find foo -type f|sort|xargs cat) to do the comparison -- sufficient for my needs at the time, but cleaning it up for general purpose use would essentially be rewriting the -r part of diff from scratch

Message #8 received at 21715 <at> debbugs.gnu.org (full text, mbox):

From: Jim Meyering <jim <at> meyering.net>
To: Aaron Davies <aaron.davies <at> gmail.com>
Cc: 21715 <at> debbugs.gnu.org
Subject: Re: [bug-diffutils] bug#21715: feat req: an option to skip directory
 inode comparison
Date: Sun, 15 May 2016 21:22:42 -0700

On Mon, Oct 19, 2015 at 7:27 PM, Aaron Davies <aaron.davies <at> gmail.com> wrote:
> i have a situation where diff -r of two directories fails to report differences that diff of two files in those directories shows
>
> i haven't dug into the code yet, but the directories involved are on an NFS mount of a netapp filer, one is the copy-on-write snapshot counterpart of the other, they show up as the same filesystem, and are the same inode
>
> so my guess is that there's something in the recursive traversal that says that any two directories that are on the same fs and are the same inode must have identical descendent contents and can be skipped completely
>
> this fs probably violates POSIX by doing this, but there's no easy way around it[1], so it would be very useful if diff had a command-line option to turn that optimization off
>
> i've heard anecdotal reports of other filesystems that cause the same problem
>
> here's a sample session:
>
> $ mkdir foo
> $ echo baz >foo/bar
> $ # wait until the next snapshot is created
> $ echo quux >foo/bar
> $ diff -r .snapshot/nightly.0/foo foo
> $ diff .snapshot/nightly.0/foo/bar foo/bar
> 1c1
> < baz
> ---
>> quux
> $ stat -c %i .snapshot/nightly.0/foo foo
> 69403847
> 69403847
> $
> --
> Aaron Davies
> aaron.davies <at> gmail.com
>
> [1] when i ran into this, i ended up using something like diff <(find .snapshot/nightly.0/foo -type f|sort|xargs cat) <(find foo -type f|sort|xargs cat) to do the comparison -- sufficient for my needs at the time, but cleaning it up for general purpose use would essentially be rewriting the -r part of diff from scratch

Hi Aaron,
Thanks for the suggestion, but what NetApp software are you using?
I've just tried to reproduce that on a NetApp-backed nfs-mounted directory,
and see different inode numbers for the directories:

  $ stat --format %i foo .snapshot/hourly.2016-05-15_*/foo
  97582543
  97557711

Message #11 received at 21715 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Jim Meyering <jim <at> meyering.net>, Aaron Davies <aaron.davies <at> gmail.com>
Cc: 21715 <at> debbugs.gnu.org
Subject: Re: [bug-diffutils] bug#21715: bug#21715: feat req: an option to skip
 directory inode comparison
Date: Sun, 15 May 2016 23:13:03 -0700

Jim Meyering wrote:
> Thanks for the suggestion, but what NetApp software are you using?
> I've just tried to reproduce that on a NetApp-backed nfs-mounted directory,
> and see different inode numbers for the directories:
> 
>   $ stat --format %i foo .snapshot/hourly.2016-05-15_*/foo
>   97582543
>   97557711

I can reproduce the problem on my platform: a RHEL 7 client
(3.10.0-327.10.1.el7.x86_64 kernel), with a NetApp server running a fairly old
release. The last time I asked (in 2010), they were running netapp-6.5.6 on the
file server.

As far as I know, only NetApp has the inode-number bug. It's had the bug for
many years, and I'm a bit surprised to see that they fixed it in a recent release.

Message #16 received at 21715-done <at> debbugs.gnu.org (full text, mbox):

From: Jim Meyering <jim <at> meyering.net>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: Aaron Davies <aaron.davies <at> gmail.com>, 21715-done <at> debbugs.gnu.org
Subject: Re: [bug-diffutils] bug#21715: bug#21715: feat req: an option to skip
 directory inode comparison
Date: Mon, 16 May 2016 12:28:18 -0700

On Sun, May 15, 2016 at 11:13 PM, Paul Eggert <eggert <at> cs.ucla.edu> wrote:
> Jim Meyering wrote:
>> Thanks for the suggestion, but what NetApp software are you using?
>> I've just tried to reproduce that on a NetApp-backed nfs-mounted directory,
>> and see different inode numbers for the directories:
>>
>>   $ stat --format %i foo .snapshot/hourly.2016-05-15_*/foo
>>   97582543
>>   97557711
>
> I can reproduce the problem on my platform: a RHEL 7 client
> (3.10.0-327.10.1.el7.x86_64 kernel), with a NetApp server running a fairly old
> release. The last time I asked (in 2010), they were running netapp-6.5.6 on the
> file server.
>
> As far as I know, only NetApp has the inode-number bug. It's had the bug for
> many years, and I'm a bit surprised to see that they fixed it in a recent release.

I confess I was surprised, too, after so many years.
Running `version` on the server my client used prints this:

  NetApp Release 8.3.1P2: Wed Dec 09 03:10:24 UTC 2015

As such, it feels ok to close this.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.