[dtrace-discuss] fds[] and rename(2)

[james wahlig]

I made the change to nfs for v_path to be updated on rename, but this is 
only  slightly better.  There are still cases where the path is wrong, 
consider:

$ echo hi > a
$ ln a b
$ rm a
$ echo bye > a

Now there will be two different vnodes with the same v_path.

I've thought about a way to fix this, but I'm not sure it is worth it.

Also, what happens when a directory is renamed?  The v_path for that 
directory would get updated, but what about any file in that directory 
that already has the v_path set with the old directory name?

Just my thoughts.

Jim

Eric Schrock wrote On 04/07/06 12:44,:

>The introduction of v_path was purely for observability, not
>correctness.  It's actually impossible to guarantee correctness in all
>circumstances.  That being said, we should strive to improve
>observability in the common cases.
>
>For rename() in particular, the reason it wasn't done is that due to the
>nature of the VFS interfaces, it can't be done in a generic way.  This
>means that every filesystem would need to call back into a private VFS
>interface to update the path.  
>
>There's nothing stopping bundled ON filesystems from doing this.  In
>fact, NFS was enhanced to do just this not too long ago.  It would be a
>small amount of code to fix UFS and ZFS to do this callback as well.
>
>- Eric
>
>On Fri, Apr 07, 2006 at 06:34:41PM +0100, John Levon wrote:
>  
>
>># dtrace -n 'syscall::open64:return /execname == "cat"/ { trace(fds[arg0].fi_pathname); }' &
>>dtrace: description 'syscall::open64:return ' matched 1 probe
>># touch /tmp/old.name
>># mv /tmp/old.name /tmp/new.name
>># cat /tmp/new.name
>>CPU     ID                    FUNCTION:NAME
>>  0  40825                    open64:return   /tmp/old.name
>>
>>fds[] uses ->v_path directly, but a rename(2) never updates the cached path.  I
>>assume there's a good reason that ->v_path can't be updated on rename(2)? It
>>also means that pfiles(1) can't resolve the path of the file, as well.
>>
>>regards
>>john
>>_______________________________________________
>>dtrace-discuss mailing list
>>dtrace-discuss at opensolaris.org
>>    
>>
>
>--
>Eric Schrock, Solaris Kernel Development       http://blogs.sun.com/eschrock
>_______________________________________________
>dtrace-discuss mailing list
>dtrace-discuss at opensolaris.org
>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.opensolaris.org/pipermail/dtrace-discuss/attachments/20060407/65822056/attachment.html>