Re: iSCSI vs. SMB with ZFS.
-Original Message- From: Zaphod Beeblebrox Sent: Wednesday, December 12, 2012 6:57 PM To: FreeBSD Hackers Subject: iSCSI vs. SMB with ZFS. So... I have two machines. My Fileserver is a core-2-duo machine with FreeBSD-9.1-ish ZFS, istgt and samba 3.6. My workstation is windows 7 on an i7. Both have GigE and are connected directly via a managed switch with jumbo packets (specifically 9016) enabled. Both are using tagged vlan packets to the switch (if that matters at all). My experience on samba has been that it’s slow whatever one does to tweak it (probably just too linux-centric code to start with or whatever...) Just as another datapoint – do you have tried NFS yet? Win7 has NFS available as OS component, although not installed by default? -Reko ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Re: Aqcuiring full path to running process from outside the kernel
- Original Message - From: Sergey Babkin [EMAIL PROTECTED] To: Lutz Boehne [EMAIL PROTECTED]; freebsd-hackers@freebsd.org Sent: Tuesday, August 22, 2006 8:59 PM Subject: Re: Re: Aqcuiring full path to running process from outside thekernel So why not just change the compiler to put the contents of this file into a DATA section, at some special symbol. (I presume that now it puts the messages into some kind of a COMMENT section). Then instead of reading the file manually you would have the contents of the file already pre-mapped into the memory for you when the program starts. Saves you lots of trouble. The problem is mainly that for some reason for every platform OW supports the file path is fetched somehow. I know the existing code which fetches the full path first isn't the most elegant one, but what I'm trying to do is get OW to compile first with existing code and logic, without breaking too much in the process :) But as said in earlier post of mine, I managed to achieve what I was trying with the following code - using the sysctl seems to achieve what was needed reliably enough, at least for now. int mib[4]; size_t len; mib[0] = CTL_KERN; mib[1] = KERN_PROC; mib[2] = KERN_PROC_PATHNAME; mib[3] = -1; len = PATH_MAX; /* First we try grabbing the path to executable using the sysctl MIB*/ result = sysctl(mib, 4, name, len, NULL, 0); I managed to stumble upon this about the same time I got the first reply on my question, but for fallback methods I've gotten several valuable suggestions and ideas from here, thanks! -Reko ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Aqcuiring full path to running process from outside the ?kernel
- Original Message - From: Oliver Fromme [EMAIL PROTECTED] To: freebsd-hackers@FreeBSD.ORG; [EMAIL PROTECTED] Sent: Wednesday, August 23, 2006 2:40 PM Subject: Re: Aqcuiring full path to running process from outside the ?kernel Oliver Fromme wrote: Another way would be to use /proc/$$/file (where $$ is the result from getpid()), but it only works when PROCFS is mounted on /proc, obviously. Yep, and if I or whoever will get the OW into port collection, I think demanding /proc to be mounted might be not that good idea - if the problem can be handled a way that vanilla BSD understands. Finally, maybe you don't have to know the path at all. The kernel maintains a file descriptor of the executable. lsof(8) and fstat(1) display it (as text or txt, repectively), so I assume there's a way to retrieve it from userland. If you can get access to that file descriptor, you should be able to read data from the executable without having to know its path name. I managed to do exactly that - the problem being for the moment is that all the other platforms OW supports at the moment do fetch the path somehow. Linux uses /proc, DOS, NT and OS/2 whatever etc. The logic in the resource fetching goes simplified like this: Ask the path for the current process from a library function and with the path open a handle for the executable file and then fast forward into resource part and fetch the strings needed. IMHO using the already available handle would be most elegant solution, but that would mean major rewriting in the resource handling for the other platforms, hence for now I'll settle just for trying to do this in manner compatible with existing code. (And of course something that's very simple to achieve in FBSD can be a major pain for some other platform supported by Watcom toolchain...) The latter might even be the _only_ way to access the executable file, because someone might have unliked the directory entry right after starting it, so you cannot access it anymore by path name, but only by descriptor. Or disappearing NFS mounts or other fun things Still lot to do but at least now I have managed to tackle some of the biggest problems for bootstrapping the toolchain, with lots of stuff copied from Linux build and requiring gnu make for the bootstrap... Might be that I'm trying to climb a tree with my posterior in the fore, but the thing I'm trying to achieve for now is getting the OW to bootstrap and build all the tools, then starting to change the makefiles from gnu to bsd make and then see if anything can be done to clib with my skills or whether that would be a job for more seasoned and BSD knowledgeable folks :) (There aren't that many makefiles for gnu make as the bootstrap changes pretty soon using the wmake supplied with toolchain) But enough of my rambling and thanks! -Reko ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Aqcuiring full path to running process from outside the kernel
I've been playing with Open Watcom for a bit in FreeBSD and for a while there's been one stumblim block for further advancement. Watcom uses a method for storing program messages etc. where these messages are stored as a resource file inside the executable itself. As the commands are usually invoked without the canonical path, the tools cannot find the resource portion stored inside. This far I've been looking for some solutions from which none seem to work too well. vn_fullpath (9) is running only inside kernel I think, and with the approach using kvm_openfiles and kvm_getprocs I can only get the command without the path (there are vnode etc. structures inside the kinfo_proc structure, but those seem to be unavailable from user space). Of course /proc might help in here, but I rather kept the code compilable on very vanilla system. Any pointers on how to proceed would be welcome. -Reko ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Aqcuiring full path to running process from outside the kernel
Of course I did find about the CTL_KERN.KERN_PROC.KERN_PROC_PATHNAME sysctl method of grabbing the path just about the same time Mike replied to my query... Seems that either of the ways suggested by Mike could be used as fallback. Sorry about the noise. -Reko ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
X86 machine code enter and FreeBSD kernel
I received no reply on this question at questions mailing list, so I try asking this here. Hope I'm not asking this in completely wrong list. In recent discussion in OpenWatcom lists it was noticed that at least certain addressing modes of assembler ENTER instruction causes a crash when used in Linux. GCC circumnavigates this by not emitting ENTER instructions in machine code. Linus's comment on the above issue can be found on: http://groups.google.co.nz/groups?selm=7i86ni%24b7n%241%40palladium.transmeta.com What's the status of the above feature in FreeBSD, does the kernel support the whole x86 instruction set without similar cut corners? -Reko ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
