Hi,
I am trying to trace calls to device driver strategy routine
for dtrace. My script is:
cmdkstrategy:entry
/execname == "dd"/
{
printf("blkno = %x, size = %x\n", args[0]._b_blkno._f,
args[0].b_size);
}
The script works fine with dd to a file in a ufs file system.
I get no output when doing the same to a file in a zfs file
system. The io:::start probe also does not fire.
So, what gives?
thanks,
max
Max Bruning wrote:>Hi, >I am trying to trace calls to device driver strategy routine >for dtrace. My script is: > >cmdkstrategy:entry >/execname == "dd"/ >{ > printf("blkno = %x, size = %x\n", args[0]._b_blkno._f, args[0].b_size); >} > >The script works fine with dd to a file in a ufs file system. >I get no output when doing the same to a file in a zfs file >system. The io:::start probe also does not fire. >So, what gives? > >thanks, >max > > >Just to make sure, you''re using the same disk for ufs and zfs? cmdk should be for ata/ide drives, sd for scsi drives. This script works for me, depending on what disk the pool was created for: #!/usr/sbin/dtrace -Fs cmdkstrategy:entry /execname == $$1/ { printf("cmdk!\n"); } sdstrategy:entry /execname == $$1/ { printf("sd!\n"); } eric
> Max Bruning wrote: > >> Hi, >> I am trying to trace calls to device driver strategy routine >> for dtrace. My script is: >> >> cmdkstrategy:entry >> /execname == "dd"/ >> { >> printf("blkno = %x, size = %x\n", args[0]._b_blkno._f, >> args[0].b_size); >> } >> >> The script works fine with dd to a file in a ufs file system. >> I get no output when doing the same to a file in a zfs file >> system. The io:::start probe also does not fire. >> So, what gives? >> thanks, >> max >> >>I think the io::start is not firing because no IO is happening. ZFS will defer writes to get better performance. If you write to a file opened with O_DSYNC, or fsync() io::start will fire. hth, -neel
Roch Bourbonnais - Performance Engineering
2005-Dec-02 09:05 UTC
[zfs-discuss] dtracing zfs io
Neelakanth Nadgir writes:
>
> > Max Bruning wrote:
> >
> >> Hi,
> >> I am trying to trace calls to device driver strategy routine
> >> for dtrace. My script is:
> >>
> >> cmdkstrategy:entry
> >> /execname == "dd"/
> >> {
> >> printf("blkno = %x, size = %x\n",
args[0]._b_blkno._f,
> >> args[0].b_size);
> >> }
> >>
> >> The script works fine with dd to a file in a ufs file system.
> >> I get no output when doing the same to a file in a zfs file
> >> system. The io:::start probe also does not fire.
> >> So, what gives?
> >> thanks,
> >> max
> >>
> >>
>
> I think the io::start is not firing because no IO is happening. ZFS will
> defer
> writes to get better performance. If you write to a file opened with
> O_DSYNC, or fsync() io::start will fire.
>
> hth,
> -neel
With ZFS it might be harder to map disk I/Os to applications.
The write I/O may not be started in the context of "dd".
The I/O are held in memory and commited every 5 seconds
unless something else requests an earlier commit (such as
an fsync).
Even with fsync you could see the I/O started to the intent
log (zil) but not the subsequent commiting I/O(s).
-r
____________________________________________________________________________________
Roch Bourbonnais Sun Microsystems, Icnc-Grenoble
Senior Performance Analyst 180, Avenue De L''Europe, 38330,
Montbonnot Saint Martin, France
Performance & Availability Engineering
http://icncweb.france/~rbourbon http://blogs.sun.com/roller/page/roch
Roch.Bourbonnais at Sun.Com (+33).4.76.18.83.20
Hi, Actually, I guess I should have realized that the dd was not going to work. I am using a ufs file for the backing store, so not only am I going through zfs, but also ufs and segmap. The reason I am trying to trace the reads/writes, is that I am trying to find the block number(s) that zfs is using for a file. This is easy with ufs (block numbers are in the inode), but not so obvious with zfs. I think I have found the data structure containing the offset(s), but will need to do a bit more work to get them. Once I have the data structures (and offsets), I''ll move on to the organization. I understand that some documentation on the implementation is coming soon... max On Fri, 2005-12-02 at 01:05, Roch Bourbonnais - Performance Engineering wrote:> Neelakanth Nadgir writes: > > > > > Max Bruning wrote: > > > > > >> Hi, > > >> I am trying to trace calls to device driver strategy routine > > >> for dtrace. My script is: > > >> > > >> cmdkstrategy:entry > > >> /execname == "dd"/ > > >> { > > >> printf("blkno = %x, size = %x\n", args[0]._b_blkno._f, > > >> args[0].b_size); > > >> } > > >> > > >> The script works fine with dd to a file in a ufs file system. > > >> I get no output when doing the same to a file in a zfs file > > >> system. The io:::start probe also does not fire. > > >> So, what gives? > > >> thanks, > > >> max > > >> > > >> > > > > I think the io::start is not firing because no IO is happening. ZFS will > > defer > > writes to get better performance. If you write to a file opened with > > O_DSYNC, or fsync() io::start will fire. > > > > hth, > > -neel > > With ZFS it might be harder to map disk I/Os to applications. > > The write I/O may not be started in the context of "dd". > > The I/O are held in memory and commited every 5 seconds > unless something else requests an earlier commit (such as > an fsync). > > Even with fsync you could see the I/O started to the intent > log (zil) but not the subsequent commiting I/O(s). > > -r > > ____________________________________________________________________________________ > Roch Bourbonnais Sun Microsystems, Icnc-Grenoble > Senior Performance Analyst 180, Avenue De L''Europe, 38330, > Montbonnot Saint Martin, France > Performance & Availability Engineering > http://icncweb.france/~rbourbon http://blogs.sun.com/roller/page/roch > Roch.Bourbonnais at Sun.Com (+33).4.76.18.83.20 > > _______________________________________________ > zfs-discuss mailing list > zfs-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Max Bruning wrote:>Hi, >Actually, I guess I should have realized that the dd was not >going to work. I am using a ufs file for the backing store, >so not only am I going through zfs, but also ufs and segmap. > >The reason I am trying to trace the reads/writes, is that >I am trying to find the block number(s) that zfs is using >for a file. This is easy with ufs (block numbers are in the inode), >but not so obvious with zfs. I think I have found the data structure >containing the offset(s), but will need to do a bit more >work to get them. Once I have the data structures (and offsets), >I''ll move on to the organization. I understand that some >documentation on the implementation is coming soon... > >max > >I believe what you''re looking for is zio_t::io_offset , and vdev_disk_io_start()''s call to ldi_strategy(). io_offset is in bytes and needs to be shifted over DEV_BSHIFT to get the LBA. eric>On Fri, 2005-12-02 at 01:05, Roch Bourbonnais - Performance Engineering >wrote: > > >>Neelakanth Nadgir writes: >> > >> > > Max Bruning wrote: >> > > >> > >> Hi, >> > >> I am trying to trace calls to device driver strategy routine >> > >> for dtrace. My script is: >> > >> >> > >> cmdkstrategy:entry >> > >> /execname == "dd"/ >> > >> { >> > >> printf("blkno = %x, size = %x\n", args[0]._b_blkno._f, >> > >> args[0].b_size); >> > >> } >> > >> >> > >> The script works fine with dd to a file in a ufs file system. >> > >> I get no output when doing the same to a file in a zfs file >> > >> system. The io:::start probe also does not fire. >> > >> So, what gives? >> > >> thanks, >> > >> max >> > >> >> > >> >> > >> > I think the io::start is not firing because no IO is happening. ZFS will >> > defer >> > writes to get better performance. If you write to a file opened with >> > O_DSYNC, or fsync() io::start will fire. >> > >> > hth, >> > -neel >> >>With ZFS it might be harder to map disk I/Os to applications. >> >>The write I/O may not be started in the context of "dd". >> >>The I/O are held in memory and commited every 5 seconds >>unless something else requests an earlier commit (such as >>an fsync). >> >>Even with fsync you could see the I/O started to the intent >>log (zil) but not the subsequent commiting I/O(s). >> >>-r >> >>____________________________________________________________________________________ >>Roch Bourbonnais Sun Microsystems, Icnc-Grenoble >>Senior Performance Analyst 180, Avenue De L''Europe, 38330, >> Montbonnot Saint Martin, France >>Performance & Availability Engineering >>http://icncweb.france/~rbourbon http://blogs.sun.com/roller/page/roch >>Roch.Bourbonnais at Sun.Com (+33).4.76.18.83.20 >> >>_______________________________________________ >>zfs-discuss mailing list >>zfs-discuss at opensolaris.org >>http://mail.opensolaris.org/mailman/listinfo/zfs-discuss >> >> > >_______________________________________________ >zfs-discuss mailing list >zfs-discuss at opensolaris.org >http://mail.opensolaris.org/mailman/listinfo/zfs-discuss > >
Max Bruning wrote:> Hi, > Actually, I guess I should have realized that the dd was not > going to work. I am using a ufs file for the backing store, > so not only am I going through zfs, but also ufs and segmap. > > The reason I am trying to trace the reads/writes, is that > I am trying to find the block number(s) that zfs is using > for a file. This is easy with ufs (block numbers are in the inode), > but not so obvious with zfs. I think I have found the data structure > containing the offset(s), but will need to do a bit more > work to get them. Once I have the data structures (and offsets), > I''ll move on to the organization. I understand that some > documentation on the implementation is coming soon... > > max > >Max, Yes, an on-disk format document is coming *very* soon, which should be a great help to you. Please check the ZFS community documentation page for updates (I wish I could give you the exact date, sorry). Tabriz P.S. I will send a mail out to this alias once it is posted.> On Fri, 2005-12-02 at 01:05, Roch Bourbonnais - Performance Engineering > wrote: > >> Neelakanth Nadgir writes: >> > >> > > Max Bruning wrote: >> > > >> > >> Hi, >> > >> I am trying to trace calls to device driver strategy routine >> > >> for dtrace. My script is: >> > >> >> > >> cmdkstrategy:entry >> > >> /execname == "dd"/ >> > >> { >> > >> printf("blkno = %x, size = %x\n", args[0]._b_blkno._f, >> > >> args[0].b_size); >> > >> } >> > >> >> > >> The script works fine with dd to a file in a ufs file system. >> > >> I get no output when doing the same to a file in a zfs file >> > >> system. The io:::start probe also does not fire. >> > >> So, what gives? >> > >> thanks, >> > >> max >> > >> >> > >> >> > >> > I think the io::start is not firing because no IO is happening. ZFS will >> > defer >> > writes to get better performance. If you write to a file opened with >> > O_DSYNC, or fsync() io::start will fire. >> > >> > hth, >> > -neel >> >> With ZFS it might be harder to map disk I/Os to applications. >> >> The write I/O may not be started in the context of "dd". >> >> The I/O are held in memory and commited every 5 seconds >> unless something else requests an earlier commit (such as >> an fsync). >> >> Even with fsync you could see the I/O started to the intent >> log (zil) but not the subsequent commiting I/O(s). >> >> -r >> >> ____________________________________________________________________________________ >> Roch Bourbonnais Sun Microsystems, Icnc-Grenoble >> Senior Performance Analyst 180, Avenue De L''Europe, 38330, >> Montbonnot Saint Martin, France >> Performance & Availability Engineering >> http://icncweb.france/~rbourbon http://blogs.sun.com/roller/page/roch >> Roch.Bourbonnais at Sun.Com (+33).4.76.18.83.20 >> >> _______________________________________________ >> zfs-discuss mailing list >> zfs-discuss at opensolaris.org >> http://mail.opensolaris.org/mailman/listinfo/zfs-discuss >> > > _______________________________________________ > zfs-discuss mailing list > zfs-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20051202/9e3d7659/attachment.html>