Alexander Viro wrote:
>
> On Wed, 26 Jul 2000, Jeff V. Merkey wrote:
>
> >
> > More on this problem -- here's someting weird. If I wait a few seconds
> > after typing 'chmod 444 *' on a directory of files, then I start seeing
> > write_inode() come through the vfs, however, if I do an 'ls -l' on the
> > directory immediately after I issue a chmod command, then the
> > write_inode() never seems to happen. It looks like write_inode() is
> > getting called by some sort of delayed process (who writes dirty inodes
> > back to disk). The changes don't show up changed right away after a
> > chmod call either.
> >
> > I think I'll just implement notify_change() since the vfs.txt
> > information about relying on notify_change() to default to write_inode()
> > is obviously incorrect -- there's a hole somewhere where the inode
> > permissions can get lost.
>
> Do you, by chance, do something with inodes in readdir()? I suspect that
> it should be the right place to look. Looks like you are losing the dirty
> bit on inode before it gets written...
No. I don't believe I do. Al, the codes at 207.109.151.240 -- DIR.C
has readdir() and the dentry stuff. I might be doing something else
flaky though.
>
> Eh, wait. Where does your filesystem keep inode metadata? I think I know
> one of the possible reasons, but I'ld like to hear the answer first...
The only inode meta-data I use is the inode->u.generic_ip pointer to
hold the hash head for the fat chain header/semaphore. This structure
gets assigned to the inode on read_inode() calls and zeroed when the
put_inode() gets called.
Jeff
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Jul 31 2000 - 21:00:24 EST