I found the script below in the dtrace manual:
#pragma D option quiet
BEGIN
{
printf("%10s %58s %2s %7s\n", "DEVICE",
"FILE", "RW", "MS");
}
io:::start
{
start[args[0]->b_edev, args[0]->b_blkno] = timestamp;
}
io:::done
/start[args[0]->b_edev, args[0]->b_blkno]/
{
this->elapsed = timestamp - start[args[0]->b_edev,
args[0]->b_blkno];
printf("%10s %58s %2s %3d.%03d\n", args[1]->dev_statname,
args[2]->fi_pathname, args[0]->b_flags & B_READ ?
"R" : "W",
this->elapsed / 10000000, (this->elapsed / 1000) % 1000);
start[args[0]->b_edev, args[0]->b_blkno] = 0;
}
It does not display the file name even if I am accessing a user created file.
Any ideas?
Thank you.
--
This message posted from opensolaris.org
vhiz wrote:> I found the script below in the dtrace manual: > > #pragma D option quiet > BEGIN > { > printf("%10s %58s %2s %7s\n", "DEVICE", "FILE", "RW", "MS"); > } > io:::start > { > start[args[0]->b_edev, args[0]->b_blkno] = timestamp; > } > io:::done > /start[args[0]->b_edev, args[0]->b_blkno]/ > { > this->elapsed = timestamp - start[args[0]->b_edev, args[0]->b_blkno]; > printf("%10s %58s %2s %3d.%03d\n", args[1]->dev_statname, > args[2]->fi_pathname, args[0]->b_flags & B_READ ? "R" : "W", > this->elapsed / 10000000, (this->elapsed / 1000) % 1000); > start[args[0]->b_edev, args[0]->b_blkno] = 0; > } > > > It does not display the file name even if I am accessing a user created file. Any ideas? >What filesystem is being used? If it is ufs, most likely the file is cached [i,e it is already loaded in memory] and hence no disk IO occurs to retrieve the file from the disk. If possible ''unmount'' the filesystem and mount it back and then access the file after running the script above, you should see the filename displayed. Pramod> Thank you. >
Hi Pramod,
I am using the ZFS filesystem on OpenSolaris. The thing is
that the file that my program is reading is 2.5 GB in size, which is greater
than the RAM size. Will caching still take place? And when I run the script, I
can see that the number of reads that it displays goes up quite a bit. So the
reads are being captured, just that the file name is not being displayed.
Thanks.
--
This message posted from opensolaris.org
vhiz wrote:> Hi Pramod, > > I am using the ZFS filesystem on OpenSolaris. The thing is that the file that my program is reading is 2.5 GB in size, which is greater than the RAM size. Will caching still take place? And when I run the script, I can see that the number of reads that it displays goes up quite a bit. So the reads are being captured, just that the file name is not being displayed. > >So you see <unknown> instead of the name of the file ? Notice that your script is using fi_pathname to print the pathname of the file which is undergoing IO.>From ''http://wikis.sun.com/display/DTrace/io+Provider''--snip-- The fi_name field contains the name of the file but does not include any directory components. If no file information is associated with an I/O, the fi_name field will be set to the string <none>. In some rare cases, the pathname associated with a file might be unknown. In this case, the fi_name field will be set to the string <unknown>. The fi_pathname field contains the full pathname to the file. As with fi_name, this string may be set to <none> if no file information is present, or <unknown> if the pathname associated with the file is not known. --snip-- I suspect {need to verify} that reading in the large file [more than the RAM size] is blowing out the v_path information from the vnode. Pramod> Thanks. >
I''ve never seen the file name when doing this with ZFS. My belief is that ZFS will cheerfully bundle a bunch of data together from disparate files and spit it out to disk. It''s done with taskq threads so you can''t tie the IO to a specific process. For ZFS, this just doesn''t work. Jim ---- Pramod Batni wrote:> vhiz wrote: >> Hi Pramod, >> >> I am using the ZFS filesystem on OpenSolaris. >> The thing is that the file that my program is reading is 2.5 GB in >> size, which is greater than the RAM size. Will caching still take >> place? And when I run the script, I can see that the number of reads >> that it displays goes up quite a bit. So the reads are being >> captured, just that the file name is not being displayed. >> >> > So you see <unknown> instead of the name of the file ? > > Notice that your script is using fi_pathname to print the pathname of > the file which is undergoing IO. >> From ''http://wikis.sun.com/display/DTrace/io+Provider'' > --snip-- > The fi_name field contains the name of the file but does not include > any directory components. If no file information is associated with an > I/O, the fi_name field will be set to the string <none>. In some rare > cases, the pathname associated with a file might be unknown. In this > case, the fi_name field will be set to the string <unknown>. > The fi_pathname field contains the full pathname to the file. As with > fi_name, this string may be set to <none> if no file information is > present, or <unknown> if the pathname associated with the file is not > known. > --snip-- > I suspect {need to verify} that reading in the large file [more than > the RAM size] is blowing out the v_path information from the vnode. > > Pramod > >> Thanks. >> > > _______________________________________________ > dtrace-discuss mailing list > dtrace-discuss at opensolaris.org >
James Litchfield wrote:> I''ve never seen the file name when doing this with ZFS. > My belief is that ZFS will cheerfully bundle a bunch of data > together from disparate files and spit it out to disk. It''s done > with taskq threads so you can''t tie the IO to a specific process. > For ZFS, this just doesn''t work. > > Jim > ----Thanks Jim.> > Pramod Batni wrote: >> vhiz wrote: >>> Hi Pramod, >>> >>> I am using the ZFS filesystem on OpenSolaris. >>> The thing is that the file that my program is reading is 2.5 GB in >>> size, which is greater than the RAM size. Will caching still take >>> place? And when I run the script, I can see that the number of reads >>> that it displays goes up quite a bit. So the reads are being >>> captured, just that the file name is not being displayed. >>> >>> >> >> I suspect {need to verify} that reading in the large file [more than >> the RAM size] is blowing out the v_path information from the vnode.Apologies. The previous statement is incorrect. As Jim mentions, the file name does not show up when doing IO to files on ZFS. I just checked it out on a system and yes the script does not give the name of the ZFS file which is read/written to disk. The IO''s are handled via zio''s and there appears to be no linkage from the zio to the vnode [where the name is stored] On a side note, the script does work for files residing on UFS. Pramod