Re: Adding new option to ktrace
Nikhil Dharashivkar wrote: 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. You have reason to believe that certain I/O patterns cause the crash? What driver is being used? What is the crash? 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
Crashed occured only once at client side, for some long duration test. But it is informed that at some point to monitor the testing report should have some IO trace. On 9/6/05, Scott Long [EMAIL PROTECTED] wrote: Nikhil Dharashivkar wrote: 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. You have reason to believe that certain I/O patterns cause the crash? What driver is being used? What is the crash? 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]
FFS pread causes kernel panic on loaded 5.4 server
Greetings,
We have a FreeBSD 5.4 server which we try run in production, but have
severe problems with it crashing every few days.
Having run it with DDB, it originally appeared to be filesystem and
NFS related on crash. However, I enabled dumps to swap and fired up
kgdb on the core, and it seems to go through vn_read and ffs_read,
making the impression that it is not NFS related.
I haven't yet figured enough about how to check which file the pread
tried to access, which process it was, and what the process was doing
at that time (any pointers to documentation appreciated, but I
honestly haven't looked that much yet). Any way, it seems to be
caused by pread somehow.
Can somebody make more of it using the information I have now at hand
(stack-trace follows)? This began when I upgraded the server from
FreeBSD 4.10 to FreeBSD 5.4. The server is filesystem intensive,
mainly NFS (running Samba). It appears that frames 11 and up are the
relevant ones - everything below that is initiated by the trap and DDB
itself.
P.S. Are there easy ways to access individual processes (their data,
list open files, running status, IPCs, etc. and perhaps even stack
trace of them) given a kernel core file?
-- Tom
Follows bt from gdb:
#0 doadump () at pcpu.h:160
#1 0xc046657a in db_fncall (dummy1=0, dummy2=0, dummy3=-1065484837,
dummy4=0xeb4e1850 |...binary crap...\n)
at /r+d/5.4/src/sys/ddb/db_command.c:531
#2 0xc0466388 in db_command (last_cmdp=0xc0906664, cmd_table=0x0,
aux_cmd_tablep=0xc0885e1c, aux_cmd_tablep_end=0xc0885e38)
at /r+d/5.4/src/sys/ddb/db_command.c:349
#3 0xc0466450 in db_command_loop () at /r+d/5.4/src/sys/ddb/db_command.c:455
#4 0xc0467fe9 in db_trap (type=12, code=0)
at /r+d/5.4/src/sys/ddb/db_main.c:221
#5 0xc0646483 in kdb_trap (type=12, code=0, tf=0x1)
at /r+d/5.4/src/sys/kern/subr_kdb.c:470
#6 0xc07fafc5 in trap_fatal (frame=0xeb4e19e4, eva=28)
at /r+d/5.4/src/sys/i386/i386/trap.c:812
#7 0xc07fad23 in trap_pfault (frame=0xeb4e19e4, usermode=0, eva=28)
at /r+d/5.4/src/sys/i386/i386/trap.c:735
#8 0xc07fa939 in trap (frame=
{tf_fs = -1067319272, tf_es = -699793392, tf_ds = 1048592, tf_edi =
-699757236, tf_esi = -699757236, tf_ebp = -347203024, tf_isp = -347203056,
tf_ebx = -699757236, tf_edx = 0, tf_ecx = -1024473216, tf_eax = 4, tf_trapno =
12, tf_err = 2, tf_eip = -1066976993, tf_cs = 8, tf_eflags = 66050, tf_esp =
-699757236, tf_ss = -699757236}) at /r+d/5.4/src/sys/i386/i386/trap.c:425
#9 0xc07e890a in calltrap () at /r+d/5.4/src/sys/i386/i386/exception.s:140
#10 0xc0620018 in linker_load_file (filename=0xd64a8d4c \002, result=0x1)
at /r+d/5.4/src/sys/kern/kern_linker.c:327
#11 0xc0674176 in getnewbuf (slpflag=0, slptimeo=0, size=16384, maxsize=16384)
at /r+d/5.4/src/sys/kern/vfs_bio.c:1885
#12 0xc06755fd in getblk (vp=0xc3242318, blkno=19, size=16384, slpflag=0,
slptimeo=0, flags=0) at /r+d/5.4/src/sys/kern/vfs_bio.c:2585
#13 0xc0679b32 in cluster_read (vp=0xc3242318, filesize=1302528, lblkno=19,
size=16384, cred=0x0, totread=32768, seqcount=0, bpp=0x0)
at /r+d/5.4/src/sys/kern/vfs_cluster.c:117
#14 0xc076ed72 in ffs_read (ap=0x0) at /r+d/5.4/src/sys/ufs/ffs/ffs_vnops.c:462
#15 0xc068ed9c in vn_read (fp=0xc3be1088, uio=0xeb4e1cbc,
active_cred=0xc2d55800, flags=1, td=0xc2efc780) at vnode_if.h:398
#16 0xc064f4d5 in dofileread (td=0xc2efc780, fd=61, fp=0xc3be1088,
auio=0xeb4e1cbc, offset=Unhandled dwarf expression opcode 0x93
) at file.h:233
#17 0xc064f435 in kern_preadv (td=0xc2efc780, fd=61, auio=0xeb4e1cbc,
offset=319488) at /r+d/5.4/src/sys/kern/sys_generic.c:242
#18 0xc064f2e3 in pread (td=0xc2efc780, uap=0x0)
at /r+d/5.4/src/sys/kern/sys_generic.c:151
#19 0xc07fb333 in syscall (frame=
{tf_fs = 47, tf_es = 131119, tf_ds = 137691183, tf_edi = 0, tf_esi =
319488, tf_ebp = -1077959384, tf_isp = -347202204, tf_ebx = -2008021396, tf_edx
= 137863231, tf_ecx = 61, tf_eax = 198, tf_trapno = 0, tf_err = 2, tf_eip =
-2008518601, tf_cs = 31, tf_eflags = 646, tf_esp = -1077959428, tf_ss = 47})
at /r+d/5.4/src/sys/i386/i386/trap.c:1009
#20 0xc07e895f in Xint0x80_syscall ()
at /r+d/5.4/src/sys/i386/i386/exception.s:201
--
Tom Alsberg - hacker (being the best description fitting this space)
Web page: http://www.cs.huji.ac.il/~alsbergt/
DISCLAIMER: The above message does not even necessarily represent what
my fingers have typed on the keyboard, save anything further.
___
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
On Tue, 2005-Sep-06 10:33:53 +0530, Nikhil Dharashivkar wrote: 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. It's not clear how ktrace is going to help here. The ktrXXX(9) functions place ktr_request events in a queue. A kernel thread then dumps the queue entries into a file via the normal buffer cache. The data on disk is typically about 30 seconds behind real time. If the system crashes, you will lose any events that are still in the buffer cache or ktr_todo queue. Another problem is that since ktrace generates disk I/O, it is likely to disturb your testing. A better approach would seem to be to build a circular buffer and store the I/O requests in the buffer. When the system crashes, you can look at the last entries in the buffer. -- Peter Jeremy ___ 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
Igor Shmukler [EMAIL PROTECTED] writes: You are correct about the Unix file system organization, but does it mean reliable vnode to fullname conversation is not possible? Yes. Get over it. DES -- Dag-Erling Smørgrav - [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: Adding new option to ktrace
Yes, it is ok if i loose data in ktrace queue when crash occurs. Basically, I want to give an Disk IO trace support to ktrace on FreeBSD. So, what I am thinking to use struct dio in dastrategy routine to trace the IO. I 'll use this struct to generate ktr_request. Throught ktr_writerequest it will be written in ktrace.out . Is it possible ? On 9/6/05, Peter Jeremy [EMAIL PROTECTED] wrote: On Tue, 2005-Sep-06 10:33:53 +0530, Nikhil Dharashivkar wrote: 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. It's not clear how ktrace is going to help here. The ktrXXX(9) functions place ktr_request events in a queue. A kernel thread then dumps the queue entries into a file via the normal buffer cache. The data on disk is typically about 30 seconds behind real time. If the system crashes, you will lose any events that are still in the buffer cache or ktr_todo queue. Another problem is that since ktrace generates disk I/O, it is likely to disturb your testing. A better approach would seem to be to build a circular buffer and store the I/O requests in the buffer. When the system crashes, you can look at the last entries in the buffer. -- Peter Jeremy -- 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: Adding new option to ktrace
Sorry it's struct bio instead of struct dio. On 9/6/05, Nikhil Dharashivkar [EMAIL PROTECTED] wrote: Yes, it is ok if i loose data in ktrace queue when crash occurs. Basically, I want to give an Disk IO trace support to ktrace on FreeBSD. So, what I am thinking to use struct dio in dastrategy routine to trace the IO. I 'll use this struct to generate ktr_request. Throught ktr_writerequest it will be written in ktrace.out . Is it possible ? On 9/6/05, Peter Jeremy [EMAIL PROTECTED] wrote: On Tue, 2005-Sep-06 10:33:53 +0530, Nikhil Dharashivkar wrote: 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. It's not clear how ktrace is going to help here. The ktrXXX(9) functions place ktr_request events in a queue. A kernel thread then dumps the queue entries into a file via the normal buffer cache. The data on disk is typically about 30 seconds behind real time. If the system crashes, you will lose any events that are still in the buffer cache or ktr_todo queue. Another problem is that since ktrace generates disk I/O, it is likely to disturb your testing. A better approach would seem to be to build a circular buffer and store the I/O requests in the buffer. When the system crashes, you can look at the last entries in the buffer. -- Peter Jeremy -- Thanks and Regards, Nikhil. -- 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: FreeBSD 6.0 Beta #3 - IDE Problems? (Intel / ICH6 based laptop)
--On 05 September 2005 21:52 +0400 Stanislav Sedov [EMAIL PROTECTED] wrote: How does your SATA controller operate? Try to use LEGACY mode. Do you mean in the BIOS? - If so, there's no adjustments for this that I can see in the BIOS :( Infact, in keeping with most modern laptops - the 'fiddle-ability' level in the BIOS is pretty minimal :( -Kp ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: BPF patch
Vlad GALU wrote: On 9/1/05, Vladimir Yu. Stepanov [EMAIL PROTECTED] wrote: [snip] You can always control which traffic to sniff (ingress/egress) using layer 2 filters (ether src/dst host ). It's not a simple way. BPF filter code must be used depending on type of device. For some of drivers (ppp, tun and etc) BPF filter cannot help for filtering layer 2. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Summer of Code 2005: Improve Libalias
Hi guys, Summer of Code is finished so i released my work about libalias, and i would appreciate if anyone try it out and report. There's a tarball here: http://ubi8.imc.pi.cnr.it/~flag/libalias/libalias.tgz or if you prefer perforce: http://perforce.freebsd.org/depotTreeBrowser.cgi?FSPC=//depot/projects/soc2005/libaliasHIDEDEL=NO there's a readme inside that explains pretty much everything you need to know. For more information about the project: http://wikitest.freebsd.org/moin.cgi/PaoloPisati or to summarize the changes respect to plain libalias: -run as kld in 4.x, 5.x and 6.x (actually it was already working in 6.x) -added log support to libalias kld -integrated with ipfw (nat action added to ipfw) -moved from a monolithic deisgn to a modular one -every protocol supported (except for tcp, udp, ip and icmp) is now a module loadable at run time -module works both when libalias run as kld or user land lib -something else that i don't remember now... Feel free to report about bugs or design issue, bye -- Paolo ___ 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 Mon, Sep 05, 2005 at 01:41:00PM +0100, Karl Pielorz wrote: 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] 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. ___ 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 Mon, Sep 05, 2005 at 04:50:21PM +0100, Karl Pielorz wrote: --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)... How does your SATA controller operate? Try to use LEGACY mode. ___ 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
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 Scott ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-scsi To unsubscribe, send any mail to [EMAIL PROTECTED] -- Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. - Brian W. Kernighan ___ 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
On Tue, 6 Sep 2005, Peter Jeremy wrote: On Tue, 2005-Sep-06 10:33:53 +0530, Nikhil Dharashivkar wrote: 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. It's not clear how ktrace is going to help here. The ktrXXX(9) functions place ktr_request events in a queue. A kernel thread then dumps the queue entries into a file via the normal buffer cache. The data on disk is typically about 30 seconds behind real time. If the system crashes, you will lose any events that are still in the buffer cache or ktr_todo queue. Another problem is that since ktrace generates disk I/O, it is likely to disturb your testing. A better approach would seem to be to build a circular buffer and store the I/O requests in the buffer. When the system crashes, you can look at the last entries in the buffer. ktrace is indeed probably the wrong layer to do this analysis, if it is firmly believed to be a SCSI layer problem, since process level I/O events often map weakly to device level I/O events -- i.e., directory operations are substantially divorced from the block operations that implement them due to soft updates, write buffering, write combining, etc. KTR(9) supports tracing of GEOM-layer I/O events to an in-memory buffer which can be retrieved from a coredump using ktrdump. Adding additional instrumentation, say in CAM or a device driver, is pretty straight forward and probably a useful way to approach this problem. 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
On Tue, 6 Sep 2005, Nikhil Dharashivkar wrote: Yes, it is ok if i loose data in ktrace queue when crash occurs. Basically, I want to give an Disk IO trace support to ktrace on FreeBSD. So, what I am thinking to use struct dio in dastrategy routine to trace the IO. I 'll use this struct to generate ktr_request. Throught ktr_writerequest it will be written in ktrace.out . Is it possible ? Try taking a look at KTR(9) and ktrdump(8) for information on ktr, the in-kernel trace facility. ktrace(1) is almost entirely about tracing process level system call behavior, and not structured for kernel event tracing except in that context. I think you'll find KTR(9) is much more what you're looking for, and among other things, you can extract the results from both live kernels and kernel crash dumps. Robert N M Watson On 9/6/05, Peter Jeremy [EMAIL PROTECTED] wrote: On Tue, 2005-Sep-06 10:33:53 +0530, Nikhil Dharashivkar wrote: 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. It's not clear how ktrace is going to help here. The ktrXXX(9) functions place ktr_request events in a queue. A kernel thread then dumps the queue entries into a file via the normal buffer cache. The data on disk is typically about 30 seconds behind real time. If the system crashes, you will lose any events that are still in the buffer cache or ktr_todo queue. Another problem is that since ktrace generates disk I/O, it is likely to disturb your testing. A better approach would seem to be to build a circular buffer and store the I/O requests in the buffer. When the system crashes, you can look at the last entries in the buffer. -- Peter Jeremy -- 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] ___ 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
You are correct about the Unix file system organization, but does it mean reliable vnode to fullname conversation is not possible? Yes. Get over it. Well, I do not think it is a Yes. I very much think it is a No. You should have continued reading my email 'til the middle or even farther. ___ 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
Igor Shmukler [EMAIL PROTECTED] writes: Dag-Erling Smørgrav [EMAIL PROTECTED] writes: Igor Shmukler [EMAIL PROTECTED] writes: You are correct about the Unix file system organization, but does it mean reliable vnode to fullname conversation is not possible? Yes. Get over it. Well, I do not think it is a Yes. I very much think it is a No. You should have continued reading my email 'til the middle or even farther. I did. You just don't get it. A file may be associated with zero, one or more names and none of these names are more correct or authoritative than any of the others. If a user does 'ln /bin/ls /tmp' (assuming /bin and /tmp are on the same filesystem), it may be obvious to you that /bin/ls is the real name is /tmp/ls is just an alias, but it is not obvious to the kernel. In fact, the kernel is unable to see any difference at all between these two names. Storing the name that was used to access a file in the vnode does not solve anything, because the vnode is shared by all users of that file, regardless of which name they used to access it, and there is no guarantee that the name that was used to access a file two seconds ago still references the same file, or any file at all; the file may have been renamed or deleted, or a new filesystem may have been mounted that covers the namespace that file was in. In summary: THERE IS NO WAY TO UNIQUELY AND RELIABLY MAP A VNODE BACK TO A NAME, and I wish people would stop insisting that there must be. All the world is not MS-DOS. DES -- Dag-Erling Smørgrav - [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[2]: vn_fullpath() again
On Tue, 6 Sep 2005, Igor Shmukler wrote: You are correct about the Unix file system organization, but does it mean reliable vnode to fullname conversation is not possible? Yes. Get over it. Well, I do not think it is a Yes. I very much think it is a No. You should have continued reading my email 'til the middle or even farther. There are various tricks that can be played to increase the chances of finding a name in the name cache, but those tricks run out quickly on systems like NFS servers where files can be accessed without being looked up since the last boot, or with background fsck. This is a fundamental property of the UNIX file system design, and it while it offers some quite powerful capabilities, nothing changes the fact that names are fundamentally second class systems in the file system and VFS design. The main tricks that can be played are: - Don't purge intermediate but unused nodes from the name cache. A specific design choice in FreeBSD has been to allow cache entries for unused nodes to be removes so that the nodes can be reused. On systems that rapidly consume vnodes, this allows more vnodes to be recycled, so means more memory available. However, it also means that it is less likely to be possible to reconstruct a name from the name cache. - Maintain references to cache entries instead of vnodes when accessing leaf files. This is actually somewhat the approach taken by Linux -- typically the hardest name to identify is the last segment to reach a file, since files can have hard links (and directories typically don't). That name can rapidly be invalidated due to renaming, unlinking, linking, and so on, and hence can be quite stale, but if you assume the name space is static, this will help out with the files don't have parents problem. - With a minor redesign of UFS, eliminating hard links, it is possible to add a directory back-pointer to the parent of a file. In this case, there is an authoritative reference to the parent. Mind you, this comes with many down-sides: Apple attempted to ship a UNIX system without support for hard links, and had to rapidly hack support for it back into the file system. - Maintain a parent back-pointer for files in the vnode, reflecting the last directory used to reach the file, so that you can search that directory to find a possible name. This requires different reference management behavior, prevents directories from falling out of the cache if a file reached via the directory is in use, and will also require walking directories, which can be very expensive. At heart, though, fundamental issues remain: files can have no names, or they can be looked up using a name that is removed, yet still have another name. They can have several names. They can be accessed without any lookup. The same name can refer to several files due to mountpoint covering. Throughout the design, names are assumed to be only fleetingly valid (during the lookup), and of secondary importance after that. Most systems I've looked at try to work around a lack of names in two ways: (1) They treat the name as something valid only at time of lookup. For example, the Solaris audit system captures a name used to look up a node, and after that it is the responsibility of the consumer of the audit trail to identify any name operations that might affect the name of an object in use, if names are important. Typically they have to handle three names during lookup: path to process root, path from process root to cwd, and path from cwd to file. (2) Apple has an underlying file system, HFS+, that actually maintains a fairly strong notion of directory hierarchy, via its catalog, so you can look up parent nodes. They maintain a vnode backpointer from children to parents in VFS, set up during lookup. However, this breaks for several reasons: volfs, which allows access to files by device + inode number, NFS, which allows access to files not by path, and their hacks to re-add hard links using a special directory, which can result in no sensible name being returned at all. This is why if you look at Darwin/Mac OS X audit trails, you'll often just see lists of inode numbers and device numbers instead of names. (3) They attempt to strengthen the name cache, either lowering the ability to recycle system memory for intermediate directories, or accepting more stale data. Either way, the approaches fall down in the face of the fundamental design choice to deprioritize names: NFS, direct inode access, hard links, mount point grafting. (4) Maintain parallel data structures, such as used by HADB, to construct directory trees, and fall back on expensive disk searching algorithms to handle edge cases, rename, NFS access, and so on. Robert N M Watson ___ freebsd-hackers@freebsd.org mailing list
Re[2]: vn_fullpath() again
Perhaps, I do not get it or maybe you are do not getting my point. There are times when resolving would not be possible or a name returned is not necessarily the one used when file was first accessed. We have discussed it here and everyone agreed on that. The hardlinks or files unlinked while vnode is still open are corner cases. The unlink is a bit more difficult to deal with, but hardlinks are probably not a big issue. As long as we can get A name, we may not even need to know THE name. I am pleasantly surprised to know that fabric of the universe is not MSDOS. :) Igor Shmukler [EMAIL PROTECTED] writes: Dag-Erling SmЬrgrav [EMAIL PROTECTED] writes: Igor Shmukler [EMAIL PROTECTED] writes: You are correct about the Unix file system organization, but does it mean reliable vnode to fullname conversation is not possible? Yes. Get over it. Well, I do not think it is a Yes. I very much think it is a No. You should have continued reading my email 'til the middle or even farther. I did. You just don't get it. A file may be associated with zero, one or more names and none of these names are more correct or authoritative than any of the others. If a user does 'ln /bin/ls /tmp' (assuming /bin and /tmp are on the same filesystem), it may be obvious to you that /bin/ls is the real name is /tmp/ls is just an alias, but it is not obvious to the kernel. In fact, the kernel is unable to see any difference at all between these two names. Storing the name that was used to access a file in the vnode does not solve anything, because the vnode is shared by all users of that file, regardless of which name they used to access it, and there is no guarantee that the name that was used to access a file two seconds ago still references the same file, or any file at all; the file may have been renamed or deleted, or a new filesystem may have been mounted that covers the namespace that file was in. In summary: THERE IS NO WAY TO UNIQUELY AND RELIABLY MAP A VNODE BACK TO A NAME, and I wish people would stop insisting that there must be. All the world is not MS-DOS. DES -- Dag-Erling SmЬrgrav - [EMAIL PROTECTED] Играй, общайся! Скачай новую версию М-Агента http://r.mail.ru/cln2659/agent.mail.ru ___ 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 2005-09-06 19:27, Igor Shmukler [EMAIL PROTECTED] wrote: Perhaps, I do not get it or maybe you are do not getting my point. There are times when resolving would not be possible or a name returned is not necessarily the one used when file was first accessed. We have discussed it here and everyone agreed on that. The hardlinks or files unlinked while vnode is still open are corner cases. The unlink is a bit more difficult to deal with, but hardlinks are probably not a big issue. As long as we can get A name, we may not even need to know THE name. Why does it make sense to get name A in the following scenario then? user 1 creates file A user 1 hardlinks this to B user 1 gets the real name of A user 2 deletes file A user 2 creates a new file called A user 1 tries to access A and gets something unexpected Corner cases and their handling *is* important. Find another way to do whatever it is you're thinking you can do with the real name of a vnode. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
accept: Invalid argument
Hi,
In a daemon loop, i am using accept() to accept
incoming connections.
while(1) {
if((fd = accept(socketd, (struct sockaddr *) addr,
addrlen)) == -1) {
syslog(LOG_ERR, accept: %s, strerror(errno));
continue;
}
else {
...
}
accept always fails. What is wrong? i could create
socket and i got a positive integer value as socket
descriptor. following is from syslog:
Sep 6 17:20:50 devel pro[99227]: accept: Invalid
argument
Sep 6 17:21:20 devel last message repeated 204686
times
What is wrong? i am calling accept before fork().. So
i don't think child process affecting parent process.
thanks and regards...
- erkan
__
Click here to donate to the Hurricane Katrina relief effort.
http://store.yahoo.com/redcross-donate3/
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re[3]: vn_fullpath() again
Robert, Thank you very much for a detailed reply. I was aware of many of the things you mentioned, but it never hurts to hear something one more time. How do you feel about small incremental improvements to name lookup? What about looking up device name in the structure itself for VCHR nodes then prepending /dev/ and returning device name, as a first step? If incremental improvements sound like a good idea, maybe we could do a few small modifications that would cover some additional cases. Would not it be good? Thank you in advance, Igor -Original Message- From: Robert Watson [EMAIL PROTECTED] To: Igor Shmukler [EMAIL PROTECTED] Date: Tue, 6 Sep 2005 16:21:47 +0100 (BST) Subject: Re[2]: vn_fullpath() again On Tue, 6 Sep 2005, Igor Shmukler wrote: You are correct about the Unix file system organization, but does it mean reliable vnode to fullname conversation is not possible? Yes. Get over it. Well, I do not think it is a Yes. I very much think it is a No. You should have continued reading my email 'til the middle or even farther. There are various tricks that can be played to increase the chances of finding a name in the name cache, but those tricks run out quickly on systems like NFS servers where files can be accessed without being looked up since the last boot, or with background fsck. This is a fundamental property of the UNIX file system design, and it while it offers some quite powerful capabilities, nothing changes the fact that names are fundamentally second class systems in the file system and VFS design. The main tricks that can be played are: - Don't purge intermediate but unused nodes from the name cache. A specific design choice in FreeBSD has been to allow cache entries for unused nodes to be removes so that the nodes can be reused. On systems that rapidly consume vnodes, this allows more vnodes to be recycled, so means more memory available. However, it also means that it is less likely to be possible to reconstruct a name from the name cache. - Maintain references to cache entries instead of vnodes when accessing leaf files. This is actually somewhat the approach taken by Linux -- typically the hardest name to identify is the last segment to reach a file, since files can have hard links (and directories typically don't). That name can rapidly be invalidated due to renaming, unlinking, linking, and so on, and hence can be quite stale, but if you assume the name space is static, this will help out with the files don't have parents problem. - With a minor redesign of UFS, eliminating hard links, it is possible to add a directory back-pointer to the parent of a file. In this case, there is an authoritative reference to the parent. Mind you, this comes with many down-sides: Apple attempted to ship a UNIX system without support for hard links, and had to rapidly hack support for it back into the file system. - Maintain a parent back-pointer for files in the vnode, reflecting the last directory used to reach the file, so that you can search that directory to find a possible name. This requires different reference management behavior, prevents directories from falling out of the cache if a file reached via the directory is in use, and will also require walking directories, which can be very expensive. At heart, though, fundamental issues remain: files can have no names, or they can be looked up using a name that is removed, yet still have another name. They can have several names. They can be accessed without any lookup. The same name can refer to several files due to mountpoint covering. Throughout the design, names are assumed to be only fleetingly valid (during the lookup), and of secondary importance after that. Most systems I've looked at try to work around a lack of names in two ways: (1) They treat the name as something valid only at time of lookup. For example, the Solaris audit system captures a name used to look up a node, and after that it is the responsibility of the consumer of the audit trail to identify any name operations that might affect the name of an object in use, if names are important. Typically they have to handle three names during lookup: path to process root, path from process root to cwd, and path from cwd to file. (2) Apple has an underlying file system, HFS+, that actually maintains a fairly strong notion of directory hierarchy, via its catalog, so you can look up parent nodes. They maintain a vnode backpointer from children to parents in VFS, set up during lookup. However, this breaks for several reasons: volfs, which allows access to files by device + inode number, NFS, which allows access to files not by path, and their hacks to re-add hard links using a special directory, which can result in
Sendmail Procmail
I want to run spamassassin site-wide, but can't get mail to it I've followed the instructions but for some reason email isn't going through sendmail, into procmail, and then filtering through spamassassin. I'm running FreeBSD 4.6, sendmail 8.12 and have procmail installed on the server. Procmail runs fine from individual accounts, but I'm having trouble getting it to run site-wide from sendmail so I can filter email through spamassassin. I've got a file called procmailrc in /etc, /etc/mail and /usr/local/etc. My sendmail.mc file looks something like this: ... FEATURE(access_db, `hash -o -TTMPF /etc/mail/access') FEATURE(blacklist_recipients) FEATURE(local_procmail, `/usr/bin/procmail') FEATURE(mailertable, `hash -o /etc/mail/mailertable') FEATURE(virtusertable, `hash -o /etc/mail/virtusertable') MAILER(procmail) MAILER(local) MAILER(smtp) ... and my procmailrc looks like this: ... DROPPRIVS=yes :0fw * 256000 | /usr/local/bin/spamc -f ... All the pieces seem work fine if run from the command line, but there are no spamassassin headers in any email messages. I don't see spamc or spamd running, so I'm guessing the problem is either in procmail finding the rc file, or sendmail using procmail. Does anyone have any ideas or suggestions? What am I missing? -- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Sendmail Procmail
Steve Suhre wrote: I want to run spamassassin site-wide, but can't get mail to it I've followed the instructions but for some reason email isn't going through sendmail, into procmail, and then filtering through spamassassin. I'm running FreeBSD 4.6, sendmail 8.12 and have procmail installed on the server. Procmail runs fine from individual accounts, but I'm having trouble getting it to run site-wide from sendmail so I can filter email through spamassassin. I've got a file called procmailrc in /etc, /etc/mail and /usr/local/etc. My sendmail.mc file looks something like this: .. FEATURE(access_db, `hash -o -TTMPF /etc/mail/access') FEATURE(blacklist_recipients) FEATURE(local_procmail, `/usr/bin/procmail') FEATURE(mailertable, `hash -o /etc/mail/mailertable') FEATURE(virtusertable, `hash -o /etc/mail/virtusertable') MAILER(procmail) MAILER(local) MAILER(smtp) Just a vague guess (as Ive never run spamassasin, but do run majordomo, needing pipes ) ... Maybe One of those features includes SMRSH or similar ? Send Mail Restricted SHell doesnt allow pipes, last config I recall. -- Julian Stacey. Consultant Unix Net Sys. Eng., Munich. http://berklix.com Mail Ascii not HTML. Ihr Rauch = mein allergischer Kopfschmerzen. ___ 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
[snip] I did. You just don't get it. A file may be associated with zero, one or more names and none of these names are more correct or authoritative than any of the others. If a user does 'ln /bin/ls /tmp' (assuming /bin and /tmp are on the same filesystem), it may be obvious to you that /bin/ls is the real name is /tmp/ls is just an alias, but it is not obvious to the kernel. In fact, the kernel is unable to see any difference at all between these two names. Yes -but when a user requests a mapping of vnode to pathname, he is asking in the context of files he has accessed (recently). In this context, the name cache does suffice -but unfortunately not every unix variant provides access to it. regards -kamal ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: accept: Invalid argument
Did you issue listen(2) call before accepting connections?
Sergey.
erkan kolemen wrote:
Hi,
In a daemon loop, i am using accept() to accept
incoming connections.
while(1) {
if((fd = accept(socketd, (struct sockaddr *) addr,
addrlen)) == -1) {
syslog(LOG_ERR, accept: %s, strerror(errno));
continue;
}
else {
...
}
accept always fails. What is wrong? i could create
socket and i got a positive integer value as socket
descriptor. following is from syslog:
Sep 6 17:20:50 devel pro[99227]: accept: Invalid
argument
Sep 6 17:21:20 devel last message repeated 204686
times
What is wrong? i am calling accept before fork().. So
i don't think child process affecting parent process.
thanks and regards...
- erkan
__
Click here to donate to the Hurricane Katrina relief effort.
http://store.yahoo.com/redcross-donate3/
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [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: accept: Invalid argument
Did you call bind() and especially listen() before accept()?
victor cruceru
On 9/6/05, erkan kolemen [EMAIL PROTECTED] wrote:
Hi,
In a daemon loop, i am using accept() to accept
incoming connections.
while(1) {
if((fd = accept(socketd, (struct sockaddr *) addr,
addrlen)) == -1) {
syslog(LOG_ERR, accept: %s, strerror(errno));
continue;
}
else {
...
}
accept always fails. What is wrong? i could create
socket and i got a positive integer value as socket
descriptor. following is from syslog:
Sep 6 17:20:50 devel pro[99227]: accept: Invalid
argument
Sep 6 17:21:20 devel last message repeated 204686
times
What is wrong? i am calling accept before fork().. So
i don't think child process affecting parent process.
thanks and regards...
- erkan
__
Click here to donate to the Hurricane Katrina relief effort.
http://store.yahoo.com/redcross-donate3/
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [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: Sendmail Procmail
... FEATURE(local_procmail, `/usr/bin/procmail') MAILER(procmail) MAILER(local) ... You don't need MAILER(procmail) if you are using FEATURE(local_procmail). On the other hand, procmail as a local mailer will only read the user's ~/.procmailrc, *not* the system wide one. If you want to use procmail as a system wide filter, there are examples of how to do this in the EXAMPLES section of the procmail man page. You will need to drop FEATURE(local_procmail) and just use MAILER(procmail) and add rules or mailertable entries to get mail to go to that mailer. However, that may mean you no longer evaluate user ~/.procmailrc files. You'll have to research the procmail side more. I don't see spamc or spamd running That is a problem. spamd needs to be running for spamc to contact it. Check /usr/local/etc/rc.d/sa-spamd.sh. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re[3]: vn_fullpath() again
On Tue, 6 Sep 2005, Igor Shmukler wrote: Thank you very much for a detailed reply. I was aware of many of the things you mentioned, but it never hurts to hear something one more time. How do you feel about small incremental improvements to name lookup? What about looking up device name in the structure itself for VCHR nodes then prepending /dev/ and returning device name, as a first step? If incremental improvements sound like a good idea, maybe we could do a few small modifications that would cover some additional cases. Would not it be good? This is an issue of some importance to me, as reliable naming is very useful in the world of security -- especially for audit trails, where you want to provide reliable security log information for intrusion detection and post-mortems. I have a few things in mind -- I'd like to offer something like a best-effort VOP_GETPATH(), which will be implemented by synthetic file systems to return a path to the file system root for a node. This would be implemented by file systems like procfs and devfs to handle cases where the name cache wasn't used. For example, it would return 'ptyp0' when pointed at /dev/ptyp0, and then it will be the name system's responsibility to figure out from the file system root back through the next file system. For file systems not supporting it, EOPNOTSUPP might be returned. One of the particularly not-possible-to-handle-cases is NFS, though, and I'm not sure we should expect to be able to hand it. As with the Sun/BSD/UNIX VFS/UFS, it really is designed around the idea of only files and directories being first class objects, not names. There's no mechanism for cache invalidation, unlike with local file systems, however, so we may simply be screwed here :-). Robert N M Watson Thank you in advance, Igor -Original Message- From: Robert Watson [EMAIL PROTECTED] To: Igor Shmukler [EMAIL PROTECTED] Date: Tue, 6 Sep 2005 16:21:47 +0100 (BST) Subject: Re[2]: vn_fullpath() again On Tue, 6 Sep 2005, Igor Shmukler wrote: You are correct about the Unix file system organization, but does it mean reliable vnode to fullname conversation is not possible? Yes. Get over it. Well, I do not think it is a Yes. I very much think it is a No. You should have continued reading my email 'til the middle or even farther. There are various tricks that can be played to increase the chances of finding a name in the name cache, but those tricks run out quickly on systems like NFS servers where files can be accessed without being looked up since the last boot, or with background fsck. This is a fundamental property of the UNIX file system design, and it while it offers some quite powerful capabilities, nothing changes the fact that names are fundamentally second class systems in the file system and VFS design. The main tricks that can be played are: - Don't purge intermediate but unused nodes from the name cache. A specific design choice in FreeBSD has been to allow cache entries for unused nodes to be removes so that the nodes can be reused. On systems that rapidly consume vnodes, this allows more vnodes to be recycled, so means more memory available. However, it also means that it is less likely to be possible to reconstruct a name from the name cache. - Maintain references to cache entries instead of vnodes when accessing leaf files. This is actually somewhat the approach taken by Linux -- typically the hardest name to identify is the last segment to reach a file, since files can have hard links (and directories typically don't). That name can rapidly be invalidated due to renaming, unlinking, linking, and so on, and hence can be quite stale, but if you assume the name space is static, this will help out with the files don't have parents problem. - With a minor redesign of UFS, eliminating hard links, it is possible to add a directory back-pointer to the parent of a file. In this case, there is an authoritative reference to the parent. Mind you, this comes with many down-sides: Apple attempted to ship a UNIX system without support for hard links, and had to rapidly hack support for it back into the file system. - Maintain a parent back-pointer for files in the vnode, reflecting the last directory used to reach the file, so that you can search that directory to find a possible name. This requires different reference management behavior, prevents directories from falling out of the cache if a file reached via the directory is in use, and will also require walking directories, which can be very expensive. At heart, though, fundamental issues remain: files can have no names, or they can be looked up using a name that is removed, yet still have another name. They can have several names. They can be accessed without any lookup. The same name can refer to several files due to mountpoint covering. Throughout the design, names are
Re: accept: Invalid argument
Also the 3rd argument for accept must be positive.
See man accept.
victor cruceru.
On 9/6/05, victor cruceru [EMAIL PROTECTED] wrote:
Did you call bind() and especially listen() before accept()?
victor cruceru
On 9/6/05, erkan kolemen [EMAIL PROTECTED] wrote:
Hi,
In a daemon loop, i am using accept() to accept
incoming connections.
while(1) {
if((fd = accept(socketd, (struct sockaddr *) addr,
addrlen)) == -1) {
syslog(LOG_ERR, accept: %s, strerror(errno));
continue;
}
else {
...
}
accept always fails. What is wrong? i could create
socket and i got a positive integer value as socket
descriptor. following is from syslog:
Sep 6 17:20:50 devel pro[99227]: accept: Invalid
argument
Sep 6 17:21:20 devel last message repeated 204686
times
What is wrong? i am calling accept before fork().. So
i don't think child process affecting parent process.
thanks and regards...
- erkan
__
Click here to donate to the Hurricane Katrina relief effort.
http://store.yahoo.com/redcross-donate3/
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [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: accept: Invalid argument
you're right;
i added following before accept()
addrlen = sizeof(struct sockaddr);
From manual:
therwise, the addrlen argument is a value-result
argument; it should initially contain the amount of
space pointed to by addr;
thanks
- erkan
--- victor cruceru [EMAIL PROTECTED] wrote:
Also the 3rd argument for accept must be positive.
See man accept.
victor cruceru.
On 9/6/05, victor cruceru [EMAIL PROTECTED]
wrote:
Did you call bind() and especially listen() before
accept()?
victor cruceru
On 9/6/05, erkan kolemen [EMAIL PROTECTED]
wrote:
Hi,
In a daemon loop, i am using accept() to accept
incoming connections.
while(1) {
if((fd = accept(socketd, (struct sockaddr *)
addr,
addrlen)) == -1) {
syslog(LOG_ERR, accept: %s,
strerror(errno));
continue;
}
else {
...
}
accept always fails. What is wrong? i could
create
socket and i got a positive integer value as
socket
descriptor. following is from syslog:
Sep 6 17:20:50 devel pro[99227]: accept:
Invalid
argument
Sep 6 17:21:20 devel last message repeated
204686
times
What is wrong? i am calling accept before
fork().. So
i don't think child process affecting parent
process.
thanks and regards...
- erkan
__
Click here to donate to the Hurricane Katrina
relief effort.
http://store.yahoo.com/redcross-donate3/
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to
[EMAIL PROTECTED]
__
Click here to donate to the Hurricane Katrina relief effort.
http://store.yahoo.com/redcross-donate3/
___
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 Tue, 6 Sep 2005, Kamal R. Prasad wrote: one or more names and none of these names are more correct or authoritative than any of the others. If a user does 'ln /bin/ls /tmp' (assuming /bin and /tmp are on the same filesystem), it may be obvious to you that /bin/ls is the real name is /tmp/ls is just an alias, but it is not obvious to the kernel. In fact, the kernel is unable to see any difference at all between these two names. Yes -but when a user requests a mapping of vnode to pathname, he is asking in the context of files he has accessed (recently). In this context, the name cache does suffice -but unfortunately not every unix variant provides access to it. regards -kamal I suppose it depends a lot on what it is you plan to use the path for. For the purposes of audit, we've concluded that in fact we don't even need to re-generate the path, we'll simply use the path as requested by the user when a path was entered. I.e., our definition of recently is immediately. Other less immediate definitions of recently are a bit of a problem though, since file access often happens over the course of months or years after the initial lookup took place, at which point things an be very, very stale. For example, programs often open log files and hold them open for extended periods; likewise libraries, data files, directories, and so on. How recently is recently? One tenth of a second? One second? Ten seconds? Ten minutes? Ten hours? Ten days? Ten weeks? Ten years? FreeBSD operates on all of these time scales... Right now the FreeBSD name cache reliably returns paths for a short period of time after they are looked up -- the further you get from the initial lookup, the less reliable they become. The reliability is largely affected by two factors: the fact that this is a cache, and things fall out of the cache, and the fact that the name space is quite mutable and invalidates entries in the cache. The third case of unreliability which is addressable is cases where synthetic file systems simply don't use the cache -- i.e., devfs. My proposal for dealing with this is simply to allow those synthetic file systems to return a name if they can. I think modifying them to use the name cache doesn't make sense however, since in many cases you don't want to cache: i.e., lookups of /dev/ptmx with the pts driver, or /proc/curproc, and caching would defeat the point. 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: Sendmail Procmail
On Sep 6, 2005, at 9:58 AM, Gregory Neil Shapiro wrote: ... FEATURE(local_procmail, `/usr/bin/procmail') MAILER(procmail) MAILER(local) ... You don't need MAILER(procmail) if you are using FEATURE (local_procmail). On the other hand, procmail as a local mailer will only read the user's ~/.procmailrc, *not* the system wide one. If you want to use procmail as a system wide filter, there are examples of how to do this in the EXAMPLES section of the procmail man page. You will need to drop FEATURE(local_procmail) and just use MAILER(procmail) and add rules or mailertable entries to get mail to go to that mailer. However, that may mean you no longer evaluate user ~/.procmailrc files. You'll have to research the procmail side more. I have both MAILER(procmail) and FEATURE(local_procmail) in my .mc and site wide (/usr/local/etc/procmailrc) works fine. Is your procmail really in /usr/bin? I don't see spamc or spamd running That is a problem. spamd needs to be running for spamc to contact it. Check /usr/local/etc/rc.d/sa-spamd.sh. Right, if spamd isn't running it doesn't matter if the procmail setup is correct since SA will never get called. Dan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rc sequencing issue / mountcritremote
On Sat, Sep 03, 2005 at 03:33:54PM -0400, Tuc at T-B-O-H wrote: On Sat, Sep 03, 2005 at 12:20:41PM -0400, Tuc at T-B-O-H wrote: The problem I'm having is that when it attempts to remotely mount the NFS filesystem I need, there are no support programs running, namely (I THINK) : /etc/rc.d/rpcbind /etc/rc.d/nfsclient /etc/rc.d/mountd /etc/rc.d/nfsd /etc/rc.d/nfslocking This is wrong, you don't need anything to mount remote NFS filesystems. nfsclient only sets some useful sysctls. See handbook for details. nfsclient not only does sysctls, but also runs rpc.umntall via a dependency. I would still think the best time to do this is before the remote filesystem is mounted. Since there are other items that need rpcbind, it should be started first, and again I think before the filesystem. In checking more, the mountd isn't needed. The nfsd seems to take into account nfsserver, rpcbind, mountd and a sysctl. However, the biggest one after rpcbind I would think is nfslocking. It runs rpc.statd and rpc.lockd. I've run into ALOT of problems with things if locking isn't running. So isn't this also necessary before the mount? I know I use the remote filesystem very soon after its mounted, so it would need to be running very early on. So, even with the others not running, wouldn't I need rpcbind and nfslocking done just before remotemountcrit? One other thing I didn't touch too much on, is what about the DNS resolution for the remote mount? named isn't running until much later, so it hangs Isn't that something that should be running so the resolution can happen? The apparent mismatch in ordering comes from the fact that /usr may not be assumed to exist until after mountcritremote and thus the commands you think should run before this point can not be run until later. I believe it would be better if mountcritremote only mounted critical files systems, not all of them, but we don't have the infrastructure to support that at the moment. To address you specific points, locking will start working the moment nfslocking is run so that's not a major issue. Any program that requires an essentially fully functional system should specifically require DAEMON. As to DNS, don't do that. You simply can't rely on DNS during the early part of the boot process, that's been the case forever and likely will remain so. -- Brooks -- Any statement of the form X is the one, true Y is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 pgpMey5jNL66a.pgp Description: PGP signature
Intel PRO/Wireless 2200BG/2915ABG
Hi, hackers. Does anybody here work already on this piece of hardware? I'm very interested in getting it work under FreeBSD and ready to help. -- Nick Strebkov Public key: http://humgat.org/~nick/pubkey.txt fpr: 552C 88D6 895B 6E64 F277 D367 8A70 8132 47F5 C1B6 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Intel PRO/Wireless 2200BG/2915ABG
From: Nick Strebkov Does anybody here work already on this piece of hardware? I'm very interested in getting it work under FreeBSD and ready to help. The iwi driver supports these cards. You'll want to get in touch with Sam Leffler[1] and Damien Bergamini[2] and probably help get the iwi driver fully ported and working with FreeBSD's 802.11 framework. Sam will likely be able to list off the known problems with the FreeBSD import of the driver. [1] Guru working on the net80211 framework. Email: [EMAIL PROTECTED] [2] Author of the iwi, iwp and ral drivers. Email: [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: Intel PRO/Wireless 2200BG/2915ABG
Guys, Does anybody here work already on this piece of hardware? I'm very interested in getting it work under FreeBSD and ready to help. Thanks for your answers. I have 2915ABG and Belkin F5D8230-4 access point. Will it be enough to install RELENG_6 to play with iwi stuff? -- Nick Strebkov Public key: http://humgat.org/~nick/pubkey.txt fpr: 552C 88D6 895B 6E64 F277 D367 8A70 8132 47F5 C1B6 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Intel PRO/Wireless 2200BG/2915ABG
From: Nick Strebkov Thanks for your answers. I have 2915ABG and Belkin F5D8230-4 access point. Will it be enough to install RELENG_6 to play with iwi stuff? That depends. You'll need firmware before you can use the iwi driver. One of show-stopper problems with the iwi driver is that connections which spew large numbers of packets (cvs, cvsup, remote X, etc.) will make the iwi device suddenly stop working. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Intel PRO/Wireless 2200BG/2915ABG
On Tue, Sep 06, 2005 at 03:30:18PM -0700, Darren Pilgrim wrote: From: Nick Strebkov Thanks for your answers. I have 2915ABG and Belkin F5D8230-4 access point. Will it be enough to install RELENG_6 to play with iwi stuff? That depends. You'll need firmware before you can use the iwi driver. One of show-stopper problems with the iwi driver is that connections which spew large numbers of packets (cvs, cvsup, remote X, etc.) will make the iwi device suddenly stop working. Hm... It's really sad, but how does this prob relates to selection CURRENT vs RELENG_6? -- Nick Strebkov Public key: http://humgat.org/~nick/pubkey.txt fpr: 552C 88D6 895B 6E64 F277 D367 8A70 8132 47F5 C1B6 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Intel PRO/Wireless 2200BG/2915ABG
From: Nick Strebkov On Tue, Sep 06, 2005 at 03:30:18PM -0700, Darren Pilgrim wrote: From: Nick Strebkov Thanks for your answers. I have 2915ABG and Belkin F5D8230-4 access point. Will it be enough to install RELENG_6 to play with iwi stuff? That depends. You'll need firmware before you can use the iwi driver. One of show-stopper problems with the iwi driver is that connections which spew large numbers of packets (cvs, cvsup, remote X, etc.) will make the iwi device suddenly stop working. Hm... It's really sad, but how does this prob relates to selection CURRENT vs RELENG_6? In terms of if_iwi, CURRENT and RELENG_6 are pretty much in sync. The only difference I can see is that CURRENT is bringing in support for WME/802.11e. ___ 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
At the cost of drawing ire from FreeBSD core developers, I will point out that reverse-resolution is hardly a black-and-white issue. There are many shades of grey, and there is a huge problem set that can either be solved or 99.99% of the way solved (greatly reducing the time required to solve the remainder) with a more robust namecache implementation. FreeBSD's implementation is basically at the lowest rung on the ladder. DragonFly's is a couple of rungs up. DragonFly can returned a guarenteed consistent path (even through renames of any component) to any open vnode as well as tell you whether the namespace used to access the vnode was remove()'d. For an auditing program or for generating a high level journaling stream to generate a mirror on a remote host, that covers 99.99% of the filesystem. NFS views from the client are one of those shades of gray, since files and directories can be ripped up by other clients or the server, but since clients have to assume a certain level of consistency anyway it's hardly a show stopper from the point of view of any real-life use or need. Hardlinks are one of those shades of gray, but they hardly invalidate the many uses that namepath resolution can be put to. 99.99% of the files on most filesystems are either not hardlinked or not removed once acccessed, after all, and at least with UFS a directory CAN'T be hardlinked. The important thing is to reduce the problem set to something manageable. For a mirroring program or an auditing program, being able to get valid paths in real time for nearly all the changes made to a filesystem is no small thing, and you at least get a definitive red flag for any hardlinks (simply by the fact that st_nlink is greater then one) and can do it the slow way (aka scan/index all files with st_nlink 1) for the remaining few, and track realtime namespace operations on hardlinked files after that (which is very easy to do). As to how to solve the basic problem in FreeBSD... well, it basically isn't solvable to the degree that DFly has solved it unless someone good spends a lot of time rewriting the namecache code and the VFS API. BUT, short of doing that, I think it *IS* possible to rewrite enough of the namecache to at least make the namecache records consistent against the active vnodes and to not throw away namecache records for the directory chain leading up to any vnode. It's even possible to generate the chain for vnodes generated from file handles (inode numbers), which an NFS server op has to do quite often, because the directory is available in those cases (DragonFly does this for NFS server operations so I know it's possible). It is even possible to do even less work to maintain the associations... you don't even NEED to have a working namecache, in fact. All you need are ref'd directory vnodes in a chain from any leaf leading to the mount point... basically taking the vnode-v_dd field and changing it from a verifier heuristic to a real, ref'd directory vnode, with appropriate feedback from filesystem to fix things up for rename(), and mark the namecache entry as invalid for remove(). Given a valid directory vnode chain, you can ALWAYS regenerate a valid path (maybe not the only path, but a *VALID* path) to any vnode for all cases except the case where you have a hardlinked file that you have open()'d and remove()'d. Very few programs care about open but completely unlinked files. DragonFly can provide the original path to such a file, but it flags it as having been removed and one can almost certainly ignore such files for, e.g. filesystem mirroring and even for auditing if the file is not otherwise important. Considering the rarity of the case, it would be sufficient to simply red-flag the condition (which you can reliably do with a v_dd directory chain implementation). In summary, the implementation would be: * Maintain vref'd v_dd pointers in leaf vnodes representing the directory tree to a leaf so they can't go away until the leaf vnode goes away. * Handle NFS server based file handle - vnode translation by resolving the chain to root (doable because the NFS server has access to the related directory vnode for all such translations). * Use the namecache when it exists, and * Create related namecache records when asked to resolve a full path when it doesn't by recursing upwards through the directory chains and scanning the directory to locate the name translation for the underlying vnode. DragonFly does this for the NFS server (see the cache_inefficient_scan() procedure in kern/vfs_cache.c in the DFly source for an example). That is more achievable in FreeBSD. In fact, I would say that it is
Re: vn_fullpath() again
On 9/6/05, Robert Watson [EMAIL PROTECTED] wrote: On Tue, 6 Sep 2005, Kamal R. Prasad wrote: one or more names and none of these names are more correct or authoritative than any of the others. If a user does 'ln /bin/ls /tmp' (assuming /bin and /tmp are on the same filesystem), it may be obvious to you that /bin/ls is the real name is /tmp/ls is just an alias, but it is not obvious to the kernel. In fact, the kernel is unable to see any difference at all between these two names. Yes -but when a user requests a mapping of vnode to pathname, he is asking in the context of files he has accessed (recently). In this context, the name cache does suffice -but unfortunately not every unix variant provides access to it. regards -kamal I suppose it depends a lot on what it is you plan to use the path for. For the purposes of audit, we've concluded that in fact we don't even need to re-generate the path, we'll simply use the path as requested by the user when a path was entered. I.e., our definition of recently is immediately. Thanks for the info detailed herewith. My purpose is similar to lsof utility. It looks up the namecache and provides a list of open filenames for a given process and it turns out that lsof is cross-platform and quite popular. Just curious -how huge would the name cache be -if all open files had a vnode--pathname mapping recorded? The mappings can be dropped when the file descriptor's reference count drops to 0. regards -kamal Other less immediate definitions of recently are a bit of a problem though, since file access often happens over the course of months or years after the initial lookup took place, at which point things an be very, very stale. For example, programs often open log files and hold them open for extended periods; likewise libraries, data files, directories, and so on. How recently is recently? One tenth of a second? One second? Ten seconds? Ten minutes? Ten hours? Ten days? Ten weeks? Ten years? FreeBSD operates on all of these time scales... Right now the FreeBSD name cache reliably returns paths for a short period of time after they are looked up -- the further you get from the initial lookup, the less reliable they become. The reliability is largely affected by two factors: the fact that this is a cache, and things fall out of the cache, and the fact that the name space is quite mutable and invalidates entries in the cache. The third case of unreliability which is addressable is cases where synthetic file systems simply don't use the cache -- i.e., devfs. My proposal for dealing with this is simply to allow those synthetic file systems to return a name if they can. I think modifying them to use the name cache doesn't make sense however, since in many cases you don't want to cache: i.e., lookups of /dev/ptmx with the pts driver, or /proc/curproc, and caching would defeat the point. 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]
