Re: DTrace (or other monitor) access to LBA of a block device

2010-12-07 Thread Alexander Leidinger
Quoting Andriy Gapon (from Mon, 06 Dec 2010 18:08:26 +0200): on 06/12/2010 16:59 Alexander Leidinger said the following: I do not think it is trivial. The amount of discussion around this does not makes me want to do a MFC. Sorry, I must have missed the discussion. Could you please clarify

Re: DTrace (or other monitor) access to LBA of a block device

2010-12-06 Thread Andriy Gapon
on 06/12/2010 16:59 Alexander Leidinger said the following: > I do not think it is trivial. The amount of discussion around this does not > makes > me want to do a MFC. Sorry, I must have missed the discussion. Could you please clarify what is not trivial in this case? The change itself seems to

Re: DTrace (or other monitor) access to LBA of a block device

2010-12-06 Thread Alexander Leidinger
Quoting Artem Belevich (from Sun, 5 Dec 2010 12:27:00 -0800): On Sun, Dec 5, 2010 at 11:31 AM, Andriy Gapon wrote: By the way, in order for this to work one would need r207057 applied to -8. Any chance that could be MFC'ed? http://svn.freebsd.org/viewvc/base?view=revision&revision=207057

Re: DTrace (or other monitor) access to LBA of a block device

2010-12-05 Thread Artem Belevich
On Sun, Dec 5, 2010 at 11:31 AM, Andriy Gapon wrote: >> By the way, in order for this to work one would need r207057 applied >> to -8. Any chance that could be MFC'ed? >> >> http://svn.freebsd.org/viewvc/base?view=revision&revision=207057 > > Nice catch. > > Alexander, > can that commit be trivial

Re: DTrace (or other monitor) access to LBA of a block device

2010-12-05 Thread Andriy Gapon
on 05/12/2010 20:02 Artem Belevich said the following: >> GEOM sounds like a good candidate for probing of that kind. >> >> sudo dtrace -n 'fbt:kernel:g_io_deliver:entry { printf("%s %d %d >> %d\n",stringof(args[0]->bio_from->geom->name), args[0]->bio_cmd, >> args[0]->bio_offset, args[0]->bio_lengt

Re: DTrace (or other monitor) access to LBA of a block device

2010-12-05 Thread Thomas Zander
On Sun, Dec 5, 2010 at 19:02, Artem Belevich wrote: >> GEOM sounds like a good candidate for probing of that kind. >> >> sudo dtrace -n 'fbt:kernel:g_io_deliver:entry { printf("%s %d %d >> %d\n",stringof(args[0]->bio_from->geom->name), args[0]->bio_cmd, >> args[0]->bio_offset, args[0]->bio_length)

Re: DTrace (or other monitor) access to LBA of a block device

2010-12-05 Thread Artem Belevich
> GEOM sounds like a good candidate for probing of that kind. > > sudo dtrace -n 'fbt:kernel:g_io_deliver:entry { printf("%s %d %d > %d\n",stringof(args[0]->bio_from->geom->name), args[0]->bio_cmd, > args[0]->bio_offset, args[0]->bio_length); }' By the way, in order for this to work one would need

Re: DTrace (or other monitor) access to LBA of a block device

2010-12-03 Thread Artem Belevich
On Thu, Dec 2, 2010 at 1:33 PM, Thomas Zander wrote: > Hi, > > do we have any way to monitor which LBAs of which block device are > read/written at a given time? > > I stumbled upon this, > http://southbrain.com/south/2008/02/fun-with-dtrace-and-zfs-mirror.html > >

Re: DTrace (or other monitor) access to LBA of a block device

2010-12-02 Thread Mateusz Marzantowicz
On Thu, Dec 2, 2010 at 10:33 PM, Thomas Zander < thomas.e.zan...@googlemail.com> wrote: > Hi, > > do we have any way to monitor which LBAs of which block device are > read/written at a given time? > > I stumbled upon this, > http://southbrain.com/south/2008/02/fun-with

DTrace (or other monitor) access to LBA of a block device

2010-12-02 Thread Thomas Zander
Hi, do we have any way to monitor which LBAs of which block device are read/written at a given time? I stumbled upon this, http://southbrain.com/south/2008/02/fun-with-dtrace-and-zfs-mirror.html which is pretty intriguing. Unfortunately on FreeBSD we do not have the DTrace io provider, so his

Re: Block device

2008-11-08 Thread Nicolas Rachinsky
* Scott Long <[EMAIL PROTECTED]> [2008-11-04 09:32 -0700]: > 1. disk access in the driver layer still happens on a block basis. It's > true that to the application layer, the device has character dev > semantics, meaning that arbitrary numbers of bytes can be accessed > randomly without any restri

Re: Block device

2008-11-04 Thread Ronald Klop
epartment. 4. However, in the not-so-silly-io-benchmark department, I think FreeBSD does a whole lot better because you don't have the blind caching of the block device trying to out-guess what the filesystem is trying to do. Scott This explains some things to me as a simple user reading

Re: Block device

2008-11-04 Thread Scott Long
s a whole lot better because you don't have the blind caching of the block device trying to out-guess what the filesystem is trying to do. Scott ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To u

Re: Block device

2008-11-04 Thread Max Laier
On Tuesday 04 November 2008 15:32:01 d_elbracht wrote: > Hi list, > > can someone please explain, why > stat -x /dev/da1 > > show the SCSI-Drive as a character-device ? > > Also, on the same device > > S_ISREG(st.st_mode) is false > > S_ISCHR(st.st_mode) is true http://www.free

Re: Block device

2008-11-04 Thread Patrick M. Hausen
h, all, On Tue, Nov 04, 2008 at 03:32:01PM +0100, d_elbracht wrote: > Hi list, > > can someone please explain, why > stat -x /dev/da1 > > show the SCSI-Drive as a character-device ? http://www.freebsd.org/doc/en/books/arch-handbook/driverbasics-block.html HTH, Patrick M. Hausen Leiter

Block device

2008-11-04 Thread d_elbracht
Hi list, can someone please explain, why stat -x /dev/da1 show the SCSI-Drive as a character-device ? Also, on the same device S_ISREG(st.st_mode) is false S_ISCHR(st.st_mode) is true thanks Dieter ___ freebsd-stable@f