Re: [PATCH] Add core.trustlowlevelstat for diffs in dev,ino,uid and gid

Linus Torvalds [off-list ref] writes:

I started out wanting to check the stat information as much as possible, 
but realistically, nobody probably really cares. We already effectively 
removed st_dev checking and nsec checks.

Was ignoring st_dev checking primarily for a work tree over NFS?  I think
ignoring it makes sense.  If st_dev changes, it is likely that somebody
did a "mv" of a whole repository to some other filesystem, or the
filesystem is not giving stable st_dev to us for the whole tree---it is
not like we want to detect a change to a single path that changes its
st_dev and nothing else, as no such change is likely to be useful.

IOW, maybe we should just do this, and remove over a hundred lines of dead 
code or commentary/config. And never have to worry about these kinds of 
issues with different environments again.

I like the end result.

But I am not sure about dropping the nanosecond resolution timestamps.
The area was extended recently in preparation for ext4; we can take
advantage of it to reduce the chance the racy-git avoidance codepath
triggers if we keep it.

    fba2f38 (make USE_NSEC work as expected, 2009-02-19)

    c06ff49 (Record ns-timestamps if possible, but do not use it without
    USE_NSEC, 2009-03-04)

On Sun, 26 Apr 2009, Junio C Hamano wrote:

Was ignoring st_dev checking primarily for a work tree over NFS?

Yes, but I think there were other issues too (like git repositories on 
removable media).

The inode number really has similar concerns - different operating systems 
will use different inode numbers for both NFS and for things like FAT. 
It's not nearly as noticeable, because people don't tend to switch OS's as 
much as they might switch between two machines.

I like the end result.

But I am not sure about dropping the nanosecond resolution timestamps.
The area was extended recently in preparation for ext4; we can take
advantage of it to reduce the chance the racy-git avoidance codepath
triggers if we keep it.

    fba2f38 (make USE_NSEC work as expected, 2009-02-19)

    c06ff49 (Record ns-timestamps if possible, but do not use it without
    USE_NSEC, 2009-03-04)

Hey, we can leave the NSEC support in. Admittedly removing that was about 
half the patch, but even with it left in, it would be a cleanup.

		Linus

Linus Torvalds [off-list ref] writes:

On Sun, 26 Apr 2009, Junio C Hamano wrote:

quoted

I like the end result.

But I am not sure about dropping the nanosecond resolution timestamps.
The area was extended recently in preparation for ext4; we can take
advantage of it to reduce the chance the racy-git avoidance codepath
triggers if we keep it.

    fba2f38 (make USE_NSEC work as expected, 2009-02-19)

    c06ff49 (Record ns-timestamps if possible, but do not use it without
    USE_NSEC, 2009-03-04)

Hey, we can leave the NSEC support in. Admittedly removing that was about 
half the patch, but even with it left in, it would be a cleanup.

  I think we should have the NSEC support, as it is a performance
  impromvent, at least on my laptop.  OK, not a huge improvment, but
  still.

  For git version 1.6.3.rc3 I made a litle test, and the difference was
  the following for the 'git checkout my-v2.6.25' (from my-v2.6.27):

                 for git compiled with    for git compiled without
                 'make USE_NSEC=1 ...':   the 'USE_NSEC=1' part:

   OK open calls:       13872                   14386
   OK close calls:      13872                   14386
   OK mmap2 calls:        102                     649
   OK munmap calls:        61                     608

  so, an improvment of 514 open() and close() calls, and 547 mmap2() and
  munmap() calls, for this particular test on my particular slow laptop
  disk.

  As I wrote in fba2f38 I would guess that the improvment is larger for
  a faster disk, and a SSD disk should be able to see a larger
  improvment that I did above.

  -- kjetil

måndagen den 27 april 2009 17.58.17 skrev  Kjetil Barvik:

Linus Torvalds [off-list ref] writes:

quoted

On Sun, 26 Apr 2009, Junio C Hamano wrote:

quoted

I like the end result.

But I am not sure about dropping the nanosecond resolution timestamps.
The area was extended recently in preparation for ext4; we can take
advantage of it to reduce the chance the racy-git avoidance codepath
triggers if we keep it.

    fba2f38 (make USE_NSEC work as expected, 2009-02-19)

    c06ff49 (Record ns-timestamps if possible, but do not use it without
    USE_NSEC, 2009-03-04)

Hey, we can leave the NSEC support in. Admittedly removing that was about
half the patch, but even with it left in, it would be a cleanup.

  I think we should have the NSEC support, as it is a performance
  impromvent, at least on my laptop.  OK, not a huge improvment, but
  still.

  For git version 1.6.3.rc3 I made a litle test, and the difference was
  the following for the 'git checkout my-v2.6.25' (from my-v2.6.27):

                 for git compiled with    for git compiled without
                 'make USE_NSEC=1 ...':   the 'USE_NSEC=1' part:

   OK open calls:       13872                   14386
   OK close calls:      13872                   14386
   OK mmap2 calls:        102                     649
   OK munmap calls:        61                     608

  so, an improvment of 514 open() and close() calls, and 547 mmap2() and
  munmap() calls, for this particular test on my particular slow laptop
  disk.

  As I wrote in fba2f38 I would guess that the improvment is larger for
  a faster disk, and a SSD disk should be able to see a larger
  improvment that I did above.

  -- kjetil

Did something pop up that I don't know of that prevented inclusion of this 
patch, other than the NSEC option, or will it do if just refresh the patch?

-- robin

Robin Rosenberg [off-list ref] writes:

Did something pop up that I don't know of that prevented inclusion of this 
patch, other than the NSEC option, or will it do if just refresh the patch?

I think all of us liked the general direction, and also all of us agreed
that we would want to keep NSEC support that was removed by Linus's patch.

Nobody had time or inclination to update the patch to implement the
consensus (I still had the thread in my inbox, by the way).  So "just
refresh the patch" would be the necessary first step.

On Mon, Mar 15, 2010 at 07:50, Junio C Hamano [off-list ref] wrote:

Robin Rosenberg [off-list ref] writes:

quoted

Did something pop up that I don't know of that prevented inclusion of this
patch, other than the NSEC option, or will it do if just refresh the patch?

I think all of us liked the general direction, and also all of us agreed
that we would want to keep NSEC support that was removed by Linus's patch.

Nobody had time or inclination to update the patch to implement the
consensus (I still had the thread in my inbox, by the way).  So "just
refresh the patch" would be the necessary first step.

There is an awful lot of "trust-something" variables. Maybe they can be
consolidated into a bitmask/bitfields? And a config option taking a list of
filesystem features which can be trusted for a good measure (preserving
old "trust_something" options, of course).