Re: system hangs during dump + compress usb2-drive
From: Xin Li delp...@delphij.net To: Jin Guojun jguo...@sbcglobal.net Cc: questi...@freebsd.org; hack...@freebsd.org Sent: Sun, September 30, 2012 1:07:40 PM Subject: Re: system hangs during dump + compress usb2-drive On 9/29/12 10:49 PM, Jin Guojun wrote: In FreeBSD 8.3 release (possibly in earlier release), dump a file system has 2-3GB or more content can cause system hang in a specific case (pipe to compression): dump FS-on-SATA-drive usb-drive OK dump FS-on-SATA-drive | anyCompress sata-drive OK mv a-large-dump-file from STAT drive to a USB drive OK dump small-FS-on-SATA-drive | anyCompress usb-drive OK small -- 1.8GB or less dump large-FS-on-SATA-drive | anyCompress usb-drive hang content is 3GB or larger (did not try around 2GB yet) When system hangs, no sub system, such video, network, etc, will function. Typically, the unfinished compressed dump file is around 1.5-2.7GB, so guessing dumped file content is close to or over 2GB when failure occurred. Has anyone encountered the same problem? Because this usually takes a few hours to occur, this is hard to watch how/when it happens. Is any way to debug or determine what status the system is? For starters I'd use a different console for doing procstat -kk -a and see what the system is doing. (Perhaps also top) I *think* that if it's just hanging for some time, it's probably because the system is trying to take a snapshot? It takes time on UFS when creating and removing the snapshot. Just a guess... Cheers, --- Not sure how to use a different console. No tty is functioning (neither ttyv? nor over network). You are right on a different case -- mount /dev/da0s4d /mnt# mount a usb drive cd /mnt ssh remote-liux-host tar -cf - 8GB_FS | tar -xf - In this case, doing ls -l /mnt or df will hangs, but system is still alive. The network is 45Mbps. I have no idea how long it took the tar to finish since machine is 60 km away. When I left there last Friday, only 400MB was done in one hour. I will get the processing time tomorrow. The problem we can see now is that tar (probably the pipe) process only finish with 4GB. # df Filesystem1K-blocks Used Avail Capacity Mounted on /dev/ad4s3a 1012974355348 57659038%/ devfs 1 1 0 100%/dev ... /dev/da0s4d 1027486774 4198246 941089588 0%/mnt So, I suspect this is a pipe problem, not a compress issue. ___ 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
system hangs during dump + compress usb2-drive
In FreeBSD 8.3 release (possibly in earlier release), dump a file system has 2-3GB or more content can cause system hang in a specific case (pipe to compression): dump FS-on-SATA-drive usb-drive OK dump FS-on-SATA-drive | anyCompress sata-drive OK mv a-large-dump-file from STAT drive to a USB drive OK dump small-FS-on-SATA-drive | anyCompress usb-drive OK small -- 1.8GB or less dump large-FS-on-SATA-drive | anyCompress usb-drive hang content is 3GB or larger (did not try around 2GB yet) When system hangs, no sub system, such video, network, etc, will function. Typically, the unfinished compressed dump file is around 1.5-2.7GB, so guessing dumped file content is close to or over 2GB when failure occurred. Has anyone encountered the same problem? Because this usually takes a few hours to occur, this is hard to watch how/when it happens. Is any way to debug or determine what status the system is? -Jin ___ 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
How TLS is used in Kernel thread
By looking through _pthread_create() code and find it uses a magic cookie -- TLS -- created by rtld_allocate_tls(), and passed into kernel by sysarch() via _tcb_set() / _kcb_set(). The information seems to be set by rtld (ld-elf.so.1) in digest_phdr() under tag PT_TLS. But it is very magic for where the TLS object is created and how it is passed to digest_phdr(). The whole object passed into kernel (as sd.gsbase) looks like this: TCB: __ | TLS | TCB | |__|___| Can someone give some basic exaplain on following questions? 1) What TLS stand for? 2) Where TLS object is created? (below is the tls assigned, but I couls not find where ph is from) case PT_TLS: obj-tlsindex = 1; obj-tlssize = ph-p_memsz; obj-tlsalign = ph-p_align; obj-tlsinitsize = ph-p_filesz; obj-tlsinit = (void*) ph-p_vaddr; 3) Where in kernel the TLS is used for thread operation? Thanks in advance, -Jin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
diff should not follow sym-link
I do not know what is the historical reason for program diff to follow a symbolic link during the recursive diff (-r), but it seems not to be a proper implementation. If both compared directories contains a sym-link, which point to a same file or directory, it obviously no need to compare it (not them). If both compared directories contains a sym-link, which point to a duplicated file or directory, and files or directories are duplicated in the same tree level, these files or directories will be compared any way during the recursive diff. So there is no need to follow the sym-link to compare them (just waste time by doing so). The only case that I can see that diff may follow the sym-link in recursive comparison is if the symlink is pointing to a duplicated directory/file in very different locations, which may probably rarely be created. If this is probably the only case diff -r needs to follow the sym-link, an option -L or something similar in other commands, such as ls, should be add for such purpose. Otherwise, diff -r can be loop forever on large file systems if there is some symlinks point forth and back between some directories, users may create them for easy to traversal around file systems. Then the process of diff -r a backup file system and a live file system will take a day to finish till maximum symlink number is reached, and many redundant diff information is created. See simple example below. So, we need to either disable recursive diff to follow the symlink, or we need a switch (option) to enable following symlink feature in recursive comparison of diff when a user real needs it. Any comment? -Jin - example of looping on recursive diff % create a simple test structure % dir -R test # show tree structure, in real case a and b will be a large tree total 8 drwxr-xr-x 3 jin wheel 512 Aug 14 20:25 a/ drwxr-xr-x 2 jin wheel 512 Aug 14 20:32 b/ -rw-r--r-- 1 jin wheel 4 Aug 14 20:23 x -rw-r--r-- 1 jin wheel 4 Aug 14 20:25 y test/a: total 2 drwxr-xr-x 2 jin wheel 512 Aug 14 20:25 a1/ lrwxr-xr-x 1 jin wheel4 Aug 14 20:25 x@ - ../x test/a/a1: total 0 lrwxr-xr-x 1 jin wheel 10 Aug 14 20:24 a1@ - ../../b/a1 test/b: total 0 lrwxr-xr-x 1 jin wheel 4 Aug 14 20:32 a1@ - ../a lrwxr-xr-x 1 jin wheel 4 Aug 14 20:25 x@ - ../y % mkdir test1 % cd test % tar -cf - . | ( cd ../test1 ; tar -xf - ) % cd .. ; diff -r test test1 diff: test/a/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1: Too many levels of symbolic links diff: test1/a/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1: Too many levels of symbolic links diff: test/a/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/x: Too many levels of symbolic links diff: test1/a/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/x: Too many levels of symbolic links diff: test/b/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1: Too many levels of symbolic links diff: test1/b/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1: Too many levels of symbolic links ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
problem of boot/reboot from SimpleTech SP-U25/60 USB drive on PCG-6J2L
This is my first time to install FreeBSD 5.x/6.x on a USB drive, so I am not sure if the boot/reboot problem is particular to this drive (SimpleTech SP-U25/60), or it is a generic USB issue (I do not have a second USB drive to confirm the problem). This USB device contains a WDC WD60 0VE-07HDT0 0811 drive. System 1 -- desktop ECS 848P-A7 motherboard with 2GB DDR and Intel P4 506+ CPU ASUS Symbios 875 SCSI controller issues: (1a) attach some SEAGATE ST39102LW on SCSI controller, system boot OK, (1b) if a Toshiba XM-6201B CD drive or some old SCSI drives attached, BIOS can still detect this USB drive, but it is not bootable. It looks like hardware issue. (2) After system successfully boot up, reboot/shutdown [-h, -p] will hang the system after following message: No buffer busy after final sync Uptime: 2m11s Only way to get system reboot or shutdown is to power cycle the machine. System 2 -- laptop Sony VAIO PCG-6J2L Problem:installing FreeBSD 5.x/6.x on USB drive has no problem. system cannot boot (hangs system) regardless the FreeBSD install on this laptop or from other computer. system will not respond to soft-reset or any key stroke once hangs. Power down the system is the only way to go. Boot fails immediately once anything starting show on the screen. It looks like some type of error message repeatedly spiting on the screen. It scrolls too fast to read. It seems something like: int=## ## ext=## ## Is this a generic USB drive issue or particular problem for this USB drive with this VAIO machine? Is there a workaround to make a USB drive (or this USB drive) to boot from this VAIO laptop? I need to boot this laptop from an external drive. Please let me know how can I boot an external drive (any type external drive) on this Snoy VAIO PCG-6J2L laptop. TIA -Jin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
command line switch to disable following symlink in DIFF program
Is diff program supposed to have a switch at command line to disable following (ignore) symbolic links when -r switch is given, like many other programs do? In many places, a directory or source file can be symbolically linked multiple times to different archives. Since the original source will be diffed anyway, why diff needs to follow symlinks to compare a same source multiple times? In the other case, if partition A has a symlink to somewhere in partition B, which has a symlink back to partition A , then diff -r will loop forever. I think that diff need a switch to disable following symlink to compare final object, instead, just check if symlink exists in both checked directories, like ls -P. -Jin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Very slow writing to SATA disk
Mikhail Teterin wrote: idle temperature seems to be 54C. According to smartctl, the drive runs at 56C during the copying. Its I'd double-check that (eg with a finger). If the drive really is running at 56°C, it won't last very long. It sure feels hot to the touch, but nothing is burning, of course (freshly poured tee is near 100C and never ignites the paper cup). Do you think, the high temperature explains the poor write performance? The drive still reads at tens of Mb per second... According to http://www.spacecentersystems.com/catalog/product_info.php/products_id/293088 this model's 'Ambient Temperature' spec is 5 to 55C... Generally, the temperature is not directly affecting the performance till the mechanical problem occurred due to the temperature. A few types of hard drives are manufactured with higher temperature spec., however, those drives are usually broken in 3-6 months (continuously run). Otherwise, the higher temperature is due to some mechanical problem which may slow down the performance. In your case, it seems to me that your drive temperature is at or above the upper bound that could indicate a mechanical problem. Check to see if the reading speed of this drive is normal, then, this won't be the case for now. But keep in mind, if this drive always operates at this temperature, it will not last long. The better temperature for electronic components is below 39C, and not more than 45C~50C. So, 56C can gradually damage the mechanical as well as the electronic components. -Jin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 4.9 KLDload error
Robert Watson wrote: On Fri, 7 Nov 2003, Jin Guojun [NCS] wrote: A KLD module ncs_time_ctl.ko compiled on both 4.8 and 4.9 hosts can be loaded by kldload on any 4.8 machine. But neither .ko files can be loaded on a 4.9 machine. The error is: 4.9 # kldload -v ./ncs_time_ctl.ko kldload: can't load ./ncs_time_ctl.ko: Exec format error kldload should give more error information on what function it failed to load. Is this possible a 4.9 bug in kldload? or does some KLD mechanism has been changed in 4.9-RELEASE? Is there any way to analyze what is wrong in the 4.9 LKD system? Unfortunately, the UNIX errno mechanism isn't very expressive. However, the kernel linker will send debugging output to the system console. Check dmesg and see if there's more information there. Typically, this error will be the result of a failure to link symbols in the module: either due to a symbol already present, or a missing dependency. To debug this further, look at the console output, and also compare the output of nm on the .ko built on 4.8 and 4.9 to see if its dependencies or exposed symbols have changed. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories dmesg actually tells the missing function in patched kernel. make depend make did NOT recompile the patched code somehow under 4.9. Removing the object code and recompiling the kernel fixed the problem. I will look into it to see what causes this compile problem. Thanks, -- Jin Guojun --- v --- [EMAIL PROTECTED] --- Distributed Systems Department http://www.itg.lbl.gov/~jin M/S 50B-2239Ph#:(510) 486-7531 Fax: 486-6363 Lawrence Berkeley National Laboratory, Berkeley, CA 94720 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
4.9 KLDload error
A KLD module ncs_time_ctl.ko compiled on both 4.8 and 4.9 hosts can be loaded by kldload on any 4.8 machine. But neither .ko files can be loaded on a 4.9 machine. The error is: 4.9 # kldload -v ./ncs_time_ctl.ko kldload: can't load ./ncs_time_ctl.ko: Exec format error kldload should give more error information on what function it failed to load. Is this possible a 4.9 bug in kldload? or does some KLD mechanism has been changed in 4.9-RELEASE? Is there any way to analyze what is wrong in the 4.9 LKD system? -- Jin Guojun --- v --- [EMAIL PROTECTED] --- Distributed Systems Department http://www.itg.lbl.gov/~jin M/S 50B-2239Ph#:(510) 486-7531 Fax: 486-6363 Lawrence Berkeley National Laboratory, Berkeley, CA 94720 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: nVIDIA nForece2, again
It is a vague problem on term of best performance -- what. NVidia has better memory bandwidth in AMD motherboards. However, if SATA is involved, some motherboard either lowed the memory bandwidth, or had other I/O issues. In terms of IDE performance, the AMD 760MP has the best performance in all chipsets in the world. 760 gives true 200 MB/s I/O IDE throughput, where most other chipsets only gives 100/133 MB/s on both IDE buses with 4 drives. As to onboard NIC, I do not see any performance problem on 100 Mb/s NIC. Maybe some NICs are not supported. The performance problem is on 1Gb/s NIC, especially Intel onboard NIC which chews 100% high-end CPUs. I have not had MSI K7N2 board yet. ASUS A7N8X is the similar one which works very good in most areas. I have not tested its IDE controller yet. VIA VT400 and VT600 are not very good on I/O performance. -Jin Greg 'groggy' Lehey wrote: My main machine has just fried a southbridge, and I'm looking for a replacement. From what I can see, in the AMD range, the current best performer is the nVIDIA nForece2. I've read Bill Paul's description of the problems with the onboard NIC, and if I buy one of these boards, I'll certainly swell his mailbox of disgruntled nVIDIA customers. But at a more pragmatic level, a 100 Mb/s NIC costs nothing, and I have a few spares floating around, so it's not that big a deal. Looking at what our local suppliers have to offer, the MSI K7N2 Delta boards (http://www.msi.com.tw/program/products/mainboard/mbd/pro_mbd_detail.php?UID=436) look reasonable, both in terms of performance and price. Does anybody have any experience with them? Are there any other problems with the chip set? I've heard that it has an IOAPIC on it, even for single processors. Is this an issue? Any other comments? Based on what I've read, I'd probably be putting a Barton 2600XP+ and 0.5 to 1 GB of DDR memory into it. Greg -- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Is this TCP tuning information true?
Hi, Fund a URL for TCP tuning at http://www.csm.ornl.gov/~dunigan/net100/auto.html At the bottom of the page, it says: OpenBSD/FreeBSD saved ssthresh/cwnd info for a path in the kernel routing table, as I recall? That info could be used to prime subsequent connections on the same path. Reference ? I traced the tcp_input.c/tcp_output.c (4.3-RELEASE), and did not found such information. Would someone confirm above information or point to where is the code or document for saving this ssthresh/cwnd information to the routing table? TIA, -Jin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
question on lkm / kld in 3.3-RELEASE or later
It seems that lkm is no longer working after 3.3, it complains regardless
the mod is compiled in aout or elf (setenv OBJFORMAT before doing compiling):
# modload -ezatm_mod /lkm/znatmdrv.o
ld: /kernel: malformed input file (not rel or archive)
modload: /usr/bin/ld: return code 1
So, it looks like that kld is the way to go. However, there is no
miscellaneous module under kld (/usr/share/examples/kld/{cdev, syscall}).
Below is some comment in kld/cdev/module/cdevmod.c, It says that cdev
module is "a miscellaneous module".
Will kld provide a miscellaneous module in the future? or miscellaneous
module is merged with cdev module?
Thanks for any information,
-Jin
...
#include "cdev.h"
static int cdev_load(module_t, modeventtype_t, void *);
/*
* This function is called each time the module is loaded or unloaded.
* Since we are a miscellaneous module, we have to provide whatever
* code is necessary to patch ourselves into the area we are being
* loaded to change.
*
* The stat information is basically common to all modules, so there
* is no real issue involved with stat; we will leave it lkm_nullcmd(),
* since we don't have to do anything about it.
*/
static int
cdev_load(mod, cmd, arg)
module_tmod;
modeventtype_t cmd;
void * arg;
{
int err = 0;
cdevmod.c: unmodified, readonly: line 79 of 122 [64%]
...
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: SCSI disk naming problem
See LINT on details of how to wire down scsi devices... Your proposal doesn't take adding a second scsi card into account. Well, I did not mean that has to be da0, da1, etc., but similar thing like dac0t0d0, dac0t1d0, ... dac3t4d0, etc. which is much clear what disk is. A few people does not like this one because the name is long, and it is like some commerical configuration. They said that this is Free software. Manually wiring down disks is OK for a small set of hosts. 100+ hosts with two or three controllers with 100 TB disks will be terribly pain during the setup and maintenance. -Jin On Fri, 1 Oct 1999 [EMAIL PROTECTED] wrote: Current FreeBSD SCSi disk naming mechanism is problem for using more than one disks in the chain during the disk failure. The problem is that the name is not fixed with is SCSI ID. e.g., if one disk is presented in the chain, regardless its SCSI ID, it is always named "da0"; if two disks are installed, the one with lower ID is named da0 and the other will be named as da1. When the lower ID one is crashed, then the other disk will be named as da0 (from da1) after reboot, and it is not mountable due to the name changing. If a system has a UW SCSI controller with 15 disks in the chain, when the first disk (ID = 0) crashed, all rest 14 disks will be useless until either fstab modified or another disk is added with SCSI ID = 0. Why not we use a fixed name corresponding the SCSI ID. That is, disk with ID 0 will be always named as da0, and disk with ID 1 will be always named da1, etc.? Is there problem with fixed disk naming mechanism? , To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: SCSI disk naming problem
[EMAIL PROTECTED] wrote: If memory serves me right, [EMAIL PROTECTED] wrote: See LINT on details of how to wire down scsi devices... Your proposal doesn't take adding a second scsi card into account. Well, I did not mean that has to be da0, da1, etc., but similar thing like dac0t0d0, dac0t1d0, ... dac3t4d0, etc. which is much clear what disk is. A few people does not like this one because the name is long, and it is like some commerical configuration. They said that this is Free software. That's an interesting argument on the part of a few people. The commercial UNIX I first adminned had wired down, short names for disks (rz0, rz1, rz2, ... ). This was very nice. This one does not resolve the controller problem either as [EMAIL PROTECTED] said. So, I guess dac0t0, dac0t1, ... dac3t4, will be good enough if we want to be short, but anything shorter than this will be meaningless. Manually wiring down disks is OK for a small set of hosts. 100+ hosts with two or three controllers with 100 TB disks will be terribly pain during the setup and maintenance. It depends on what you mean by "manually". Presumably, these 100+ hosts have fairly similar kernel configurations, so you only need to build a small number of "wired down" kernels, and then distribute these out to the hosts. I've found that that having wired down SCSI devices is a Good Thing (TM), and it's one of the first things that I fix when I start building kernels for a new version of FreeBSD. I guess I've just gotten used to it. Bruce. I guess you missed the point that I do want to wire down the name. This is the original debate. But, I do not want to wire down the name by hand. The system should be able to take care this simple thing. As you mentioned, digit UNIX does it, Solaris does it, why not FreeBSD? Because it is FreeWare so we cannot do some thing good as commercial UNIXs do? -Jin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: SCSI disk naming problem
[EMAIL PROTECTED] wrote: } That's an interesting argument on the part of a few people. The } commercial UNIX I first adminned had wired down, short names for disks } (rz0, rz1, rz2, ... ). This was very nice. } } This one does not resolve the controller problem either as } [EMAIL PROTECTED] said. } } So, I guess dac0t0, dac0t1, ... dac3t4, will be good enough if we want } to be short, but anything shorter than this will be meaningless. } } Well...I personally prefer the short names. On systems with multiple } controllers, the commercial UNIX I used (Ultrix) just continued its } numbering with rz0, rz1, rz2, ..., rz6, rz7, rz8, ... FreeBSD lets you } do exactly the same thing. The thing is what is rz44 representing? If kernel spits: "rz44 hardware error 105: write failure -- replace it" Which disk are you going to shutdown and replace without looking at /etc/fstab or /sys/i386/conf/CRUEENT_RUN ? What happens if when you see the message and the host is hosed and needs to be rebooted -- at this time both above files are not available -- ? I do not think dac5t4 is that worse than rz44 (just two charaters long). Maybe it is better. You immediately know the disk with ID 4 on the SCSI controller 5 is one having trouble. If you have just one disk, I think two charaters will not be a big deal anyway. However, it will be great help to identify the disk by this two charaters. } Having long device names is confusing to users who only have one disk } controller (and I'd bet this is the vast majority). It took me a long Yes or No. I know at least 7-10 sites running 50 - 100 nodes of FreeBSD. I believe there are much more than I know. How many FreeBSD servers are running in this world? A single node FreeBSD server on this planet can be a lot. A single disk FreeBSD users could be the majority at this monment, do we want more and more FreeBSD servers runnning around the world? So, we should think about the future. } time to grok the syntax of Solaris device names and I still get confused } about this. Commercial or free doesn't have anything to do with this } issue...this scheme would force users to remember and type extra } is good. (I did } miss a message or two in the middle of your discussion, apparently, and } that may have contributed to my apparently confusion.) } } But I think your proposed long names are confusing, and I claim that } that rebuilding a kernel to get wired-down device names is easy. } } Perhaps I am misunderstanding what you mean when you say "by hand". I'm } envisioning an environment where you have a lot of similarly-configured } machines. So you build a kernel (based on GENERIC) to wire down } devices ONE TIME, and distribute that kernel out to all the different } machines. If kernel can do this automatically, no one has to rebuild the kernel any more, and no one has to remember every thing that may reduce sys-admin costs. This is special for new users/sys-admins. I personal built 1MB script to setup FreeBSD over the 10 years. It is easy for me to add a couple of lines for wired down the SCSI disk name. But, what is about for the new suers and new sys-admins. Should we make things more easier for them? } Because it is FreeWare so we cannot do some thing good } as commercial UNIXs do? } } I don't understand this argument. "Free" (i.e. open source) vs. } commercial doesn't have anything to do with this issue. This was some one screamed a couple of years ago. When I pointed out we can do something good like commercial company doing, and one person jumped on top of me and said that Hey, this is FreeWare,but not commercial software, why we should do things like commercial company does? I was scared I had bad approching for FreeWare. Now I think there is nothing wrong if we can use some good idea from any one including commercial sector. So, that is why I would like to tune the name on SCSI disks. -Jin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
location of the function(recvfrom,socket...)
Dear Sir, Could you tell me where is the code of the functions(sendto, recvfrom,socket,bind...) located at FreeBSD source tree. I will appreciate your help. Thank you, Michael Jin. __ Get Your Private, Free Email at http://www.hotmail.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
location of the function(recvfrom,socket...)
Dear Sir, Could you tell me where is the code of the functions(sendto, recvfrom,socket,bind...) located at FreeBSD source tree. I will appreciate your help. Thank you, Michael Jin. __ Get Your Private, Free Email at http://www.hotmail.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
