[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Bug#369822: ls -i stats unnecessarily
From: |
Jim Meyering |
Subject: |
Re: Bug#369822: ls -i stats unnecessarily |
Date: |
Fri, 02 Jun 2006 10:07:00 +0200 |
I wrote:
> 2006-02-25 Eric Blake <address@hidden>
>
> In ls, avoid calling stat for --inode (-i), when possible.
> * src/pwd.c (NOT_AN_INODE_NUMBER, D_INO): Move to ...
> * src/system.h: ... here, for use in ...
> * src/ls.c (main): ... here. Prefer dirent.d_ino to stat when
> possible.
> (gobble_file): Add inode argument.
> (print_dir): Pass inode if available.
> (usage): Remove inaccuracy.
>
> The problem is rare enough that I won't be losing any
> sleep over it. But it would be good to fix it, or at least
> add a test case comparing st_ino vs. d_ino for every readable
> directory from "." up to "/". Then (from test failure reports)
> we can hope to get an idea of how often the problem arises.
Well, chance would have it that just minutes ago I saw this
new test fail on a solaris 8 system:
[ This test is on the trunk, only, as is the no-stat-for-inode
ls optimization. ]
./stat-vs-dirent: test failed: /export/home: d_ino(16768) != st_ino(2)
./stat-vs-dirent: This may indicate a flaw in your kernel or file system
implementation.
I see that I wrote that test less than a month ago. Humph.
And /export/home is indeed a mount point.
$ df|grep 'home$'
/dev/dsk/c0t0d0s7 1935191 949204 927932 51% /export/home
James Youngman <address@hidden> wrote:
> You could stat "/" at startup, and if its inode number is 2 (hint that
> we're probably not chrooted), trust d_ino, and don't trust it if d_ino
> is not 2 (we're probably chrooted). The check is only probabilistic,
> but it might help. It shouldn't be fooled by fsirand.
Unfortunately, that heuristic wouldn't work in this case:
$ ./stat --format=%i /
2
So at least Solaris 8 and some glibc are affected.
Unless I find a better approach, I'll turn off this optimization
by default, and add an option to turn it back on.
- Re: Bug#369822: ls -i stats unnecessarily, Jim Meyering, 2006/06/01
- Re: Bug#369822: ls -i stats unnecessarily, Jim Meyering, 2006/06/01
- Re: Bug#369822: ls -i stats unnecessarily, James Youngman, 2006/06/01
- Re: Bug#369822: ls -i stats unnecessarily,
Jim Meyering <=
- Re: Bug#369822: ls -i stats unnecessarily, Paul Eggert, 2006/06/02
- Re: Bug#369822: ls -i stats unnecessarily, Ian Jackson, 2006/06/03
- Re: Bug#369822: ls -i stats unnecessarily, James Youngman, 2006/06/03
- Re: Bug#369822: ls -i stats unnecessarily, Ian Jackson, 2006/06/03
- Re: Bug#369822: ls -i stats unnecessarily, Jim Meyering, 2006/06/02
- Re: Bug#369822: ls -i stats unnecessarily, Paul Eggert, 2006/06/03
- Re: Bug#369822: ls -i stats unnecessarily, Ian Jackson, 2006/06/05
- Re: Bug#369822: ls -i stats unnecessarily, Paul Eggert, 2006/06/05