Re: kernel.gz.aa kernel.gz.ab
On Fri, Sep 02, 2005 at 08:47:30AM -0400, John Nielsen wrote: On Friday 02 September 2005 08:35, Donatas wrote: wonder how could I decompress $subj filesthey doesn't seems to be in tar or gzip formats. files are taken from kern1.flp nad kern2.flp on 5.4-RELEASE/floppies cat kernel.gz.aa kernel.gz.ab kernel.gz gunzip kernel.gz You're still missing the first part of the file. You also need to grab kernel.gz.boot from the boot.flp image. Then you can do a: cat kernel.gz.boot kernel.gz.aa kernel.gz.ab kernel.gz Take a look at src/release/scripts/split-file.sh to see how these files are generated. Useful if you want to do an install with a custom kernel, without building a whole release. -- [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: sed not working
Rein Kadastik wrote: Giorgos Keramidas wrote: On 2005-09-03 14:17, Rein Kadastik [EMAIL PROTECTED] wrote: Rein Kadastik wrote: Well I have one guess here. In estonian alphabet, the z comes immediately after s and before t. So as the regex orders [a-z] the characters t, u, v, w, x, y are left out How to order the sed to use english alphabet? Well, My guess was right. I have a following line in the /etc/profile: export LANG=et_EE.ISO8859-15 After I expoerted LANG=en_US.ISO8859-1, the sed started to work. I did not thought that LANG parameter will also alter the alfabet and therefore the expression [a-z] does not cover the full alphabet anymore. By using a character class: [[:alpha:]] AFAIK, if you are using non-English locales, there's no guarantee that [a-z] will be the entire set of lowercase letters, or that it will only include lowercase letters, for that matter. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] Yep, I know but it does not matter. The form [a-z] is used all over the place in the FreeBSD source (1629 lines in 4.11-RELEASE-p11 and almost 1600 in 5-STABLE). Totally hopeless. Seems, that no developer have ever heard about character classes and it VERY UNSAFE to try to compile (and actually even run) FreeBSD with some other locale than C/en_US.ISO8859-1. I actually searched for existance of character classes in source code. Found around 30 matches. Mostly in manual pages. Perl configure script checks if tr supports them, but it actually never uses the featuire (even if available). I am totally dissappointed about this. I thought about reporting a bug, but as it is everywhere, there is no point to do so. I think you're blowing things out of proportion. Providing that you build world as root (which most people do), and that you don't change the LANG setting for root (think single-user mode), the following command will give you an approximate idea of which utilities are affected: $ find /usr/src -name \*.c | xargs grep -e '.*a-z' -e '.*A-Z' 25 Of these 25 hits, about half are in comments or test code that is never built. The utilities that are genuinely affected are: kbdmap, scon, ppp (when using ATM), m4 (in GNU compatibility mode), fdisk, named, cvs, diff and vi. Tim ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: sed not working
Tim Robbins wrote: Rein Kadastik wrote: Giorgos Keramidas wrote: On 2005-09-03 14:17, Rein Kadastik [EMAIL PROTECTED] wrote: Rein Kadastik wrote: Well I have one guess here. In estonian alphabet, the z comes immediately after s and before t. So as the regex orders [a-z] the characters t, u, v, w, x, y are left out How to order the sed to use english alphabet? Well, My guess was right. I have a following line in the /etc/profile: export LANG=et_EE.ISO8859-15 After I expoerted LANG=en_US.ISO8859-1, the sed started to work. I did not thought that LANG parameter will also alter the alfabet and therefore the expression [a-z] does not cover the full alphabet anymore. By using a character class: [[:alpha:]] AFAIK, if you are using non-English locales, there's no guarantee that [a-z] will be the entire set of lowercase letters, or that it will only include lowercase letters, for that matter. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] Yep, I know but it does not matter. The form [a-z] is used all over the place in the FreeBSD source (1629 lines in 4.11-RELEASE-p11 and almost 1600 in 5-STABLE). Totally hopeless. Seems, that no developer have ever heard about character classes and it VERY UNSAFE to try to compile (and actually even run) FreeBSD with some other locale than C/en_US.ISO8859-1. I actually searched for existance of character classes in source code. Found around 30 matches. Mostly in manual pages. Perl configure script checks if tr supports them, but it actually never uses the featuire (even if available). I am totally dissappointed about this. I thought about reporting a bug, but as it is everywhere, there is no point to do so. I think you're blowing things out of proportion. Providing that you build world as root (which most people do), and that you don't change the LANG setting for root (think single-user mode), the following command will give you an approximate idea of which utilities are affected: $ find /usr/src -name \*.c | xargs grep -e '.*a-z' -e '.*A-Z' 25 Of these 25 hits, about half are in comments or test code that is never built. The utilities that are genuinely affected are: kbdmap, scon, ppp (when using ATM), m4 (in GNU compatibility mode), fdisk, named, cvs, diff and vi. Tim Well not quite. For starters, the modules that fail for my buildworld are ncurses, csh/tcsh and gdb (interesting that so few as the problem itself is way bigger). Secondly there are not 25 results but a bit more (most of the regex'es are not in .c files). Third, I already sent email to Ruslan and am waiting fore a response. I am fully aware of the size of such a project and quite willing to try to make things better. And BTW my systemwide LANG is set to et_EE.ISO8859-15 which I personally like. As the system provides localization functionality, it must handle it in every situation apropriately (which is not the case right now). Peace -- Rein Rein ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
FreeBSD 6.0 Beta #3 - IDE Problems? (Intel / ICH6 based laptop)
Hi All, I recently tried to boot the FreeBSD 6.0 Beta #3 on my laptop, and ran into a problem. The hard drive controller probes as: atapci0: Intel ICH6 SATA150 contoller port 0xbfa0-0xbfaf,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 irq 17 at device 31.2 on pci0 ... ad0: 57231MB HTS726060M9AT100/MH40A6EA [116280/16/63] at ata0-master UDMA100 But I then get the following spewed out: ad0: FAILURE - READ_DMA status=51READY,DSC,ERROR error=4ABORTED LBA=11721023 ad0: FAILURE - READ_DMA status=51READY,DSC,ERROR error=4ABORTED LBA=0 ad0: FAILURE - READ_DMA status=51READY,DSC,ERROR error=4ABORTED LBA=11721022 ad0: FAILURE - READ_DMA status=51READY,DSC,ERROR error=4ABORTED LBA=1 ad0: FAILURE - READ_DMA status=51READY,DSC,ERROR error=4ABORTED LBA=11721023 ad0: FAILURE - READ_DMA status=51READY,DSC,ERROR error=4ABORTED LBA=0 ad0: FAILURE - READ_DMA status=51READY,DSC,ERROR error=4ABORTED LBA=11721017 Sysinstall cautions me that the Geometry for the drive is unlikely, and that it's using a more sensible one (it displays 7296/255/63, with 117210240 blocks). The drive itself is partitioned already (with a WinXP partition, and a FreeBSD slice, from an older 5.x install) - however, sysinstall claims it can't see any of that and the drive is all unused. The laptop itself is a Dell XPS Gen 2. Any suggestions? Thanks, -Karl ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
vn_fullpath() again
Hello hackers, all knows that vn_fullpath() is unreliable. However I really need to get a filename for a given vnode. To simplify the task, I do not care of synthetic file systems or hardlinks. I have looked through archives in hope to find a better solution. It seems that linux_getcwd() approach could help. However to make that code work for me, I need to know a directory vnode where the file resides. vnode-v_dd field looks promising. But as I understand it did not help if file name is not in a name cache. So the question: is it ever possible to get directory vnode for a given file vnode? Thank you in advance, Sergey. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 6.0 Beta #3 - IDE Problems? (Intel / ICH6 based laptop)
--On 05 September 2005 19:31 +0400 Stanislav Sedov [EMAIL PROTECTED] wrote: Try to disable ACPI - it can helps. There may be some problems with ACPI on your laptop - BIOS update sometime helps. But first try to disable ACPI during FreeBSD boot. Latest BIOS on the machine already (apparently published sometime in August, '05) - No difference at all with ACPI disabled, apart from one PNP warning [which is understandable] and appeared to be something to do with the onboard sound. -Karl ps. When I said 'slice' in my earlier post, I meant partition - the hard drive has a WinXP partition, and a FreeBSD partition with the various slices on it, which Sysinstall doesn't see at all at installation time (in case anyone was rolling eyes g)... ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Adding new option to ktrace
Hi, i want to hack the ktrace system call. Basically, I want to monitor scsi disk IO through dastrategy() routine. It seems that kern_ktrace.c implements different functions for ktrace options like -tc / -ti ... etc (see man page). So, is it possible to add new option for disk IO with new structure object containing disk io information which will be pass to ktr_submittrequest thr' ktr_request structure. Will data will be written correctly in ktrace.out and will kdump analyze that ? -- Thanks and Regards, Nikhil. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: vn_fullpath() again
On Mon, 5 Sep 2005, Sergey Uvarov wrote: all knows that vn_fullpath() is unreliable. However I really need to get a filename for a given vnode. To simplify the task, I do not care of synthetic file systems or hardlinks. I have looked through archives in hope to find a better solution. It seems that linux_getcwd() approach could help. However to make that code work for me, I need to know a directory vnode where the file resides. vnode-v_dd field looks promising. But as I understand it did not help if file name is not in a name cache. So the question: is it ever possible to get directory vnode for a given file vnode? One way to look at the problem is from the perspective of how you might derive that information from an on-disk inode. If you look at the UFS layout on-disk, you'll see that there is no pointer to a directory back from a leaf inode; in kernel, you can have a reference to a vnode with no back pointer to a directory vnode. In order to find the parent, you potentially have to iterate through all directories on the hard disk looking for the parent, which is a potentially long-running activity. It's also not at all theoretical: vnodes are often accessed without any path lookup at all. For example, background fsck may pull inodes off disk without a name lookup, and the NFS server can receive file handle references following a reboot from a live client that maintains cached references -- it will service them without performing a lookup. So unfortunately, the answer is complex: (a) you may have to search the disk for a name, and (b) you may not even find one, since there can be files without any name at all (i.e., a temporary file that has been unlinked). On non-UFS style file systems, such as HFS+, it is possible to generate a path from the file system root without extensive disk I/O. However, all common UNIX-like file systems don't have this property -- Sun's version of UFS, ext2fs/ext3fs, and so on. If the child vnode is a directory, you can just follow it's '..' link or covered vnode, of course... Robert N M Watson ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Adding new option to ktrace
Nikhil Dharashivkar wrote: Hi, i want to hack the ktrace system call. Basically, I want to monitor scsi disk IO through dastrategy() routine. It seems that kern_ktrace.c implements different functions for ktrace options like -tc / -ti ... etc (see man page). So, is it possible to add new option for disk IO with new structure object containing disk io information which will be pass to ktr_submittrequest thr' ktr_request structure. Will data will be written correctly in ktrace.out and will kdump analyze that ? What are you trying to monitor? Would the existing devstat interface work? Scott ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re[2]: vn_fullpath() again
Robert, You are correct about the Unix file system organization, but does it mean reliable vnode to fullname conversation is not possible? As long as vnode is referenced we should be able to perform the lookup for any file system. Linux does a pretty good job with d_path() and I understand Matt changed his NC to provide this. The FreeBSD name cache requires work. It could and IMHO should be improved. If there is a desire to have FreeBSD improved in this area, why doesn't someone look at a solution I submitted for returning devfs names. While a perfect solution would require serious changes to the OS, a solution that would work for referenced vnodes is easier to implement. igor. -Original Message- From: Robert Watson [EMAIL PROTECTED] To: Sergey Uvarov [EMAIL PROTECTED] Date: Mon, 5 Sep 2005 18:00:56 +0100 (BST) Subject: Re: vn_fullpath() again On Mon, 5 Sep 2005, Sergey Uvarov wrote: all knows that vn_fullpath() is unreliable. However I really need to get a filename for a given vnode. To simplify the task, I do not care of synthetic file systems or hardlinks. I have looked through archives in hope to find a better solution. It seems that linux_getcwd() approach could help. However to make that code work for me, I need to know a directory vnode where the file resides. vnode-v_dd field looks promising. But as I understand it did not help if file name is not in a name cache. So the question: is it ever possible to get directory vnode for a given file vnode? One way to look at the problem is from the perspective of how you might derive that information from an on-disk inode. If you look at the UFS layout on-disk, you'll see that there is no pointer to a directory back from a leaf inode; in kernel, you can have a reference to a vnode with no back pointer to a directory vnode. In order to find the parent, you potentially have to iterate through all directories on the hard disk looking for the parent, which is a potentially long-running activity. It's also not at all theoretical: vnodes are often accessed without any path lookup at all. For example, background fsck may pull inodes off disk without a name lookup, and the NFS server can receive file handle references following a reboot from a live client that maintains cached references -- it will service them without performing a lookup. So unfortunately, the answer is complex: (a) you may have to search the disk for a name, and (b) you may not even find one, since there can be files without any name at all (i.e., a temporary file that has been unlinked). On non-UFS style file systems, such as HFS+, it is possible to generate a path from the file system root without extensive disk I/O. However, all common UNIX-like file systems don't have this property -- Sun's version of UFS, ext2fs/ext3fs, and so on. If the child vnode is a directory, you can just follow it's '..' link or covered vnode, of course... Robert N M Watson ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Adding new option to ktrace
Rajesh S. Ghanekar wrote: Scott Long wrote: Nikhil Dharashivkar wrote: Hi, i want to hack the ktrace system call. Basically, I want to monitor scsi disk IO through dastrategy() routine. It seems that kern_ktrace.c implements different functions for ktrace options like -tc / -ti ... etc (see man page). So, is it possible to add new option for disk IO with new structure object containing disk io information which will be pass to ktr_submittrequest thr' ktr_request structure. Will data will be written correctly in ktrace.out and will kdump analyze that ? What are you trying to monitor? Would the existing devstat interface work? May be he requires how many bytes transferred (read/write) while a process is executing. I guess devstat doesn't do it from process context, it gives total IO read/writes from a device, if registred via devstat. Please correct me if I am wrong. - Rajesh There isn't a 1:1 correlation between the bytes that the userland program writes, and the bytes that actually get written to disk. Filesystem metadata writes will happen if the file needs to be extended, not to mention the access time being updated. Some writes won't even originate from a userland program, like swap writes. GEOM also decouples the I/O path, so it's not the user process that will actually do the write, it's the g_down kthread. I would think that this would make tracking I/O via ktrace very hard. Scott ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Bus DMA question
Hi, When one creates a DMA tag for a PCI device, using bus_dma_tag_create(), I see that most drivers use NULL for the parent field, at some point, but shouldn't this field actually point to the DMA tag of the bus where the device is physically attached ? --HPS ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kernel.gz.aa kernel.gz.ab
On Monday 05 September 2005 04:56 am, Matthew West wrote: On Fri, Sep 02, 2005 at 08:47:30AM -0400, John Nielsen wrote: On Friday 02 September 2005 08:35, Donatas wrote: wonder how could I decompress $subj filesthey doesn't seems to be in tar or gzip formats. files are taken from kern1.flp nad kern2.flp on 5.4-RELEASE/floppies cat kernel.gz.aa kernel.gz.ab kernel.gz gunzip kernel.gz You're still missing the first part of the file. You also need to grab kernel.gz.boot from the boot.flp image. Then you can do a: cat kernel.gz.boot kernel.gz.aa kernel.gz.ab kernel.gz That makes sense. Do you know offhand what the other file on the boot floppy is for (kernel.gz.split, I believe)? JN ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kernel.gz.aa kernel.gz.ab
On Monday 05 September 2005 07:58 pm, John Nielsen wrote: On Monday 05 September 2005 04:56 am, Matthew West wrote: On Fri, Sep 02, 2005 at 08:47:30AM -0400, John Nielsen wrote: On Friday 02 September 2005 08:35, Donatas wrote: wonder how could I decompress $subj filesthey doesn't seems to be in tar or gzip formats. files are taken from kern1.flp nad kern2.flp on 5.4-RELEASE/floppies cat kernel.gz.aa kernel.gz.ab kernel.gz gunzip kernel.gz You're still missing the first part of the file. You also need to grab kernel.gz.boot from the boot.flp image. Then you can do a: cat kernel.gz.boot kernel.gz.aa kernel.gz.ab kernel.gz That makes sense. Do you know offhand what the other file on the boot floppy is for (kernel.gz.split, I believe)? .. or I could just follow your advice: Take a look at src/release/scripts/split-file.sh to see how these files are generated. Sorry for the noise. (kenel.gz.split is the split index file) JN ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Bus DMA question
In message: [EMAIL PROTECTED] Hans Petter Selasky [EMAIL PROTECTED] writes: : When one creates a DMA tag for a PCI device, using bus_dma_tag_create(), I : see that most drivers use NULL for the parent field, at some point, but : shouldn't this field actually point to the DMA tag of the bus where the : device is physically attached ? Should be, but isn't yet. We need to add an API to the bus_if.m file. For now, pass NULL. Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Adding new option to ktrace
Yes, what rajesh saying is right , i want to print IO Bytes. On 9/6/05, Scott Long [EMAIL PROTECTED] wrote: Rajesh S. Ghanekar wrote: Scott Long wrote: Nikhil Dharashivkar wrote: Hi, i want to hack the ktrace system call. Basically, I want to monitor scsi disk IO through dastrategy() routine. It seems that kern_ktrace.c implements different functions for ktrace options like -tc / -ti ... etc (see man page). So, is it possible to add new option for disk IO with new structure object containing disk io information which will be pass to ktr_submittrequest thr' ktr_request structure. Will data will be written correctly in ktrace.out and will kdump analyze that ? What are you trying to monitor? Would the existing devstat interface work? May be he requires how many bytes transferred (read/write) while a process is executing. I guess devstat doesn't do it from process context, it gives total IO read/writes from a device, if registred via devstat. Please correct me if I am wrong. - Rajesh There isn't a 1:1 correlation between the bytes that the userland program writes, and the bytes that actually get written to disk. Filesystem metadata writes will happen if the file needs to be extended, not to mention the access time being updated. Some writes won't even originate from a userland program, like swap writes. GEOM also decouples the I/O path, so it's not the user process that will actually do the write, it's the g_down kthread. I would think that this would make tracking I/O via ktrace very hard. Scott -- Thanks and Regards, Nikhil. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kernel.gz.aa kernel.gz.ab
it is a split index file wonder how could I decompress $subj filesthey doesn't seems to be in tar or gzip formats. files are taken from kern1.flp nad kern2.flp on 5.4-RELEASE/floppies cat kernel.gz.aa kernel.gz.ab kernel.gz gunzip kernel.gz You're still missing the first part of the file. You also need to grab kernel.gz.boot from the boot.flp image. Then you can do a: cat kernel.gz.boot kernel.gz.aa kernel.gz.ab kernel.gz That makes sense. Do you know offhand what the other file on the boot floppy is for (kernel.gz.split, I believe)? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Adding new option to ktrace
Nikhil Dharashivkar wrote: Yes, what rajesh saying is right , i want to print IO Bytes. You want to capture writes coming from userland, or you want to capture all low-level disk writes? Are you trying to correlate these writes with a particular user process? Consider an mmaped file. A userland program will modify the memory fronting the file, at at some point the pagedaemon kthread will come in and flush those dirty pages, independent of the user process. Also, like I said, device strategy routines are decoupled from the syscall callers by the g_down kthread. Trying to figure out the userland thread from dastrategy that is responsible for the I/O is going to be tricky, if even possible at all. Scott On 9/6/05, Scott Long [EMAIL PROTECTED] wrote: Rajesh S. Ghanekar wrote: Scott Long wrote: Nikhil Dharashivkar wrote: Hi, i want to hack the ktrace system call. Basically, I want to monitor scsi disk IO through dastrategy() routine. It seems that kern_ktrace.c implements different functions for ktrace options like -tc / -ti ... etc (see man page). So, is it possible to add new option for disk IO with new structure object containing disk io information which will be pass to ktr_submittrequest thr' ktr_request structure. Will data will be written correctly in ktrace.out and will kdump analyze that ? What are you trying to monitor? Would the existing devstat interface work? May be he requires how many bytes transferred (read/write) while a process is executing. I guess devstat doesn't do it from process context, it gives total IO read/writes from a device, if registred via devstat. Please correct me if I am wrong. - Rajesh There isn't a 1:1 correlation between the bytes that the userland program writes, and the bytes that actually get written to disk. Filesystem metadata writes will happen if the file needs to be extended, not to mention the access time being updated. Some writes won't even originate from a userland program, like swap writes. GEOM also decouples the I/O path, so it's not the user process that will actually do the write, it's the g_down kthread. I would think that this would make tracking I/O via ktrace very hard. Scott ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Adding new option to ktrace
Hi Scott and Rajesh, Thanks for replying me. Basically what happend, while testing scsi driver on freebsd, at some point it crashes. So, there is no way to know how much IO is performed. To know the IO state just before the driver fails, i selected ktrace to print IO information whatever i ll get from dastrategy routine. On 9/6/05, Scott Long [EMAIL PROTECTED] wrote: Rajesh S. Ghanekar wrote: Scott Long wrote: Nikhil Dharashivkar wrote: Hi, i want to hack the ktrace system call. Basically, I want to monitor scsi disk IO through dastrategy() routine. It seems that kern_ktrace.c implements different functions for ktrace options like -tc / -ti ... etc (see man page). So, is it possible to add new option for disk IO with new structure object containing disk io information which will be pass to ktr_submittrequest thr' ktr_request structure. Will data will be written correctly in ktrace.out and will kdump analyze that ? What are you trying to monitor? Would the existing devstat interface work? May be he requires how many bytes transferred (read/write) while a process is executing. I guess devstat doesn't do it from process context, it gives total IO read/writes from a device, if registred via devstat. Please correct me if I am wrong. - Rajesh There isn't a 1:1 correlation between the bytes that the userland program writes, and the bytes that actually get written to disk. Filesystem metadata writes will happen if the file needs to be extended, not to mention the access time being updated. Some writes won't even originate from a userland program, like swap writes. GEOM also decouples the I/O path, so it's not the user process that will actually do the write, it's the g_down kthread. I would think that this would make tracking I/O via ktrace very hard. Scott -- Thanks and Regards, Nikhil. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
