Re: Why sshd:PermitRootLogin = no ?
: :[EMAIL PROTECTED] wrote: :>I'm afraid I don't understand your point. If without-password :>makes sshd useful to a larger subsection of users without effecting :>security on the original subsection, why wouldn't you want to make :>the change? Just because it may not make a difference for YOU doesn't :>mean that it wouldn't be a useful change to make. : :But it *can't* make it useful to any more users. How do you get the :authorized-hosts file updated? You edit it. How do you get the :configuration changed to without-password from none? You edit it. : :Same work, no obvious advantage to without-password over no, and better :obvservance of "install in the most secure way possible". Just like :the discard port is disabled in inetd.conf -- same concept. : :-- :Steve Watt KD6GGD PP-ASEL-IA ICBM: 121W 56' 57.8" / 37N 20' 14.9" I see. And at what point does editing N files make it 'easier'? 4? 5? If we were to cut the number of files you had to edit to get X to work from 5 to 3 would that be worthwhile enough to do a commit? What exactly are you arguing here? Because I don't see it. Frankly I think being able to go from 2 files to 1 to get something done, like creating an authorized_keys file for root, is well worth the commit if there are otherwise no downsides. I don't see any downsides to doing this except for a few people who seem to be arguing that status-quo is better then fixing something even if fixing that something has absolutely no effect on them. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Why sshd:PermitRootLogin = no ?
: :matt. : :i think your missing the point of my comment. : :i never said it would increase or decrease the security of the :superuser account. nor did i say it was detrimental to the :person installing it. : :what i am saying is that i dont see any real point in making :the change. if you want it enabled. do so after the installation. : :jamie. I'm afraid I don't understand your point. If without-password makes sshd useful to a larger subsection of users without effecting security on the original subsection, why wouldn't you want to make the change? Just because it may not make a difference for YOU doesn't mean that it wouldn't be a useful change to make. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: RE: hw.ata.wc && hw.ata.tags && softupdates short question
Basically write-caching becomes irrelevant when you have tags, because the host does not have to wait for a write to complete before starting the next one. When IDE tags work, write caching no longer matters. Without IDE tags you have to turn write caching on in order to get similar write performance. Without write caching or tags for IDE, the driver must wait for a write to get completely on the disk and return an acknowledgement before it can begin queueing the next write. Unfortunately IDE drives are driven by the consumer market. They just don't work all that well if write caching is turned off (and tags are a relatively new feature for IDE), which is why we turned write-caching back on by default for IDE. While this theoretically introduces the possibility of out-of-order writes, and while out of order writes have been shown to occur under certain heavy load situations, we do not know of a single case where the IDE write caching feature has actually resulted in any corrupt data. Now with that all said it may seem that IDE + tags is the perfect solution for IDE. Unfortunately IDE is a moving target.. the chances of getting a highly reliable IDE solution are fairly low. Just look at all the problems we have with something as simple as IDE+DMA. SCSI hard drives almost universally have tags so this isn't an issue with SCSI. The simple answer is that if you care at all about reliability, pay the premium for SCSI. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
dirpref MFC to -stable: patch set to test
Ok folks, here is a patchset that MFC's the dirpref code from -current
to -stable. I have done some very simple testing, but I need a couple
more eyes on the code. I want to make sure that I have MFC'd all
necessary rcs pieces.
This is what I have MFC'd:
1.36src/sbin/newfs/mkfs.c
1.35src/sbin/newfs/newfs.c
1.16src/sbin/tunefs/tunefs.c
1.75src/sys/ufs/ffs/ffs_alloc.c
1.144, 1.148, 1.159 src/sys/ufs/ffs/ffs_vfsops.c
1.20src/sys/ufs/ffs/fs.h
1.37src/sbin/newfs/newfs.8
1.15src/sbin/tunefs/tunefs.8
1.22, 1.25 src/sbin/fsck_ffs/setup.c (note: fsck/setup.c
in -stable)
I have also incorporated the snapshot changes to the superblock (fs.h)
and some of the initialization code for fsck (setup.c) to try to make
the -stable fsck compatible with a -current filesystem.
I intend to commit this patchset to -stable on Friday if no issues come
up.
testers testers...
-Matt
Index: sbin/fsck/setup.c
===
RCS file: /home/ncvs/src/sbin/fsck/Attic/setup.c,v
retrieving revision 1.17.2.2
diff -u -r1.17.2.2 setup.c
--- sbin/fsck/setup.c 2001/02/06 20:39:09 1.17.2.2
+++ sbin/fsck/setup.c 2001/09/19 00:29:36
@@ -380,6 +380,11 @@
memmove(altsblock.fs_ocsp, sblock.fs_ocsp, sizeof sblock.fs_ocsp);
altsblock.fs_csp = sblock.fs_csp;
altsblock.fs_maxcluster = sblock.fs_maxcluster;
+ altsblock.fs_contigdirs = sblock.fs_contigdirs;
+ altsblock.fs_avgfilesize = sblock.fs_avgfilesize;
+ altsblock.fs_avgfpdir = sblock.fs_avgfpdir;
+ altsblock.fs_pendingblocks = sblock.fs_pendingblocks;
+ altsblock.fs_pendinginodes = sblock.fs_pendinginodes;
memmove(altsblock.fs_fsmnt, sblock.fs_fsmnt, sizeof sblock.fs_fsmnt);
memmove(altsblock.fs_sparecon,
sblock.fs_sparecon, sizeof sblock.fs_sparecon);
Index: sbin/newfs/mkfs.c
===
RCS file: /home/ncvs/src/sbin/newfs/mkfs.c,v
retrieving revision 1.29.2.5
diff -u -r1.29.2.5 mkfs.c
--- sbin/newfs/mkfs.c 2001/08/01 08:41:02 1.29.2.5
+++ sbin/newfs/mkfs.c 2001/09/19 00:07:12
@@ -36,7 +36,7 @@
static char sccsid[] = "@(#)mkfs.c 8.11 (Berkeley) 5/3/95";
#endif
static const char rcsid[] =
- "$FreeBSD: src/sbin/newfs/mkfs.c,v 1.29.2.5 2001/08/01 08:41:02 obrien Exp $";
+ "$FreeBSD: src/sbin/newfs/mkfs.c,v 1.36 2001/04/10 08:38:52 mckusick Exp $";
#endif /* not lint */
#include
@@ -119,6 +119,8 @@
extern int nrpos; /* # of distinguished rotational positions */
extern int bbsize; /* boot block size */
extern int sbsize; /* superblock size */
+extern int avgfilesize;/* expected average file size */
+extern int avgfilesperdir; /* expected number of files per directory */
extern u_long memleft;/* virtual memory available */
extern caddr_t membase;/* start address of memory based filesystem */
extern char * filename;
@@ -273,6 +275,17 @@
printf("preposterous ntrak %d\n", sblock.fs_ntrak), exit(14);
if (sblock.fs_nsect <= 0)
printf("preposterous nsect %d\n", sblock.fs_nsect), exit(15);
+ /*
+* collect and verify the filesystem density info
+*/
+ sblock.fs_avgfilesize = avgfilesize;
+ sblock.fs_avgfpdir = avgfilesperdir;
+ if (sblock.fs_avgfilesize <= 0)
+ printf("illegal expected average file size %d\n",
+ sblock.fs_avgfilesize), exit(14);
+ if (sblock.fs_avgfpdir <= 0)
+ printf("illegal expected number of files per directory %d\n",
+ sblock.fs_avgfpdir), exit(15);
/*
* collect and verify the block and fragment sizes
*/
Index: sbin/newfs/newfs.8
===
RCS file: /home/ncvs/src/sbin/newfs/newfs.8,v
retrieving revision 1.26.2.7
diff -u -r1.26.2.7 newfs.8
--- sbin/newfs/newfs.8 2001/07/22 11:32:31 1.26.2.7
+++ sbin/newfs/newfs.8 2001/09/19 00:27:33
@@ -30,7 +30,7 @@
.\" SUCH DAMAGE.
.\"
.\" @(#)newfs.88.6 (Berkeley) 5/3/95
-.\" $FreeBSD: src/sbin/newfs/newfs.8,v 1.26.2.7 2001/07/22 11:32:31 dd Exp $
+.\" $FreeBSD: src/sbin/newfs/newfs.8,v 1.37 2001/04/10 10:36:43 nik Exp $
.\"
.Dd December 19, 2000
.Dt NEWFS 8
@@ -50,6 +50,8 @@
.Op Fl d Ar rotdelay
.Op Fl e Ar maxbpg
.Op Fl f Ar frag-size
+.Op Fl g Ar avgfilesize
+.Op Fl h Ar avfpdir
.Op Fl i Ar bytes
.Op Fl k Ar skew
.Op Fl l Ar interleave
@@ -196,6 +198,10 @@
and
.Ar blocksize .
The default is 1024 bytes.
+.It Fl g Ar avgfiles
Re:[SOLVED] 4.4-Stable Hangs while booting GENERIC Kernel.... USBproblem
:I have for years had the IRQ disabled on the USB port cos I don't use :it and wanted to free one up. The new probe must expect that the USB port is :fully functioning. The 4.3 probe gives :... Interesting. I'm not sure there's a 'fix' for it per-say, other then to enable that IRQ. but I'm glad you were able to figure out the problem! -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: panic: vm_page_remove(): page not found in hash
:On a FreeBSD 4.3-STABLE #0: Tue Jul 10 12:20:42 EDT 2001, I was trying to :do a buildworld when the box did a :panic: vm_page_remove(): page not found in hash :... Hmmm, tried it again, and same results. I had a look through the :archives and someone was seeing this on a SMP machine back in OCT, but the :problem went away when they went to a uni processor kernel. Unfortunately :the unit is on a 3ware RAID system and if I recall correctly, I cannot save :a crash to it no? Is this a known issue from around that time ? :The hardware is fairly generic Mike, does this machine use NFS? -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Is FreeBSD more secure than Windows NT or Windows 2000?
:Hi, : :One thing that makes me uncomfortable with both Linux and FreeBSD is that :unlike Windows NT, both UNIX clones seem to be less secure for a desktop :use. ( ** Note clones doesn't mean it's any less better than UNIX, it just :means, it's not officially considered UNIX by OPEN-GROUP ** ) I've used :Windows NT 4.0 since '98, Linux since '99, FreeBSD since '00 and finally :gone FreeBSD only on my laptop. However, unlike, Windows NT 4.0, other :people can get access to my confidential files! How? Well, they can just :reinstall the FreeBSD without deleting my $HOME directory and as a root, :they can access all my files! This is a great concern when my laptop gets :stolen! Windows NT is very secure in that matter. Simply reinstalling :Windows NT will not let you read someone else's file. Also, it won't let :you reinstall Windows NT without verifying that you're the right :administrator! During the reinstall, it asks for your root passwd. If :the passwd doesn't match, it won't let you reinstall unless you're willing :to reinstall from scratch (reformat or erase everything before going on to :installation procedure). Now I think that's being secure all the way. Is :there anyway I can do that with FreeBSD? For example, attaching signature :to all my files etc. : :Regards, :Sung N. Cho, :Saturday, July 21, 2001. Umm... well, you should realize something about computers: If you have physical access to the computer, you can access everything on that computer whether or not the OS allows it. There are only two ways to secure a computer such that physical access does not compromise its files. (1) Encrypt the filesystems or (2) don't put anything critical on the computer in the first place. All someone needs to do to access your NT files is to put a bootable CD into your laptop and boot an OS that doesn't ask them for a password. Poof, they have access to your NT files. Don't be fooled by UI-based security - it doesn't exist. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: -stable weird panics
:% vmstat -m -M /var/qmail/crash/vmcore.6 :Memory Totals: In UseFreeRequests :17408K137K 7909365 :% vmstat -z -M /var/qmail/crash/vmcore.6 : :ZONEusedtotal mem-use :PIPE55 4088/63K :SWAPMETA0 0 0/0K :tcpcb 303 371 160/197K :unpcb 4 1280/8K :ripcb 0 21 0/3K :tcpcb 0 0 0/0K :udpcb 41 84 7/15K :socket 354 441 66/82K :KNOTE 1 1280/8K :NFSNODE 99464 99480 31082/31087K :NFSMOUNT26 3513/18K :VNODE 105046 105046 19696/19696K :NAMEI 2 48 2/48K :VMSPACE 97 320 18/60K :PROC101 294 41/119K :DP fakepg 0 0 0/0K :PV ENTRY33850 524263 925/14335K :MAP ENTRY 10572593 49/121K :KMAP ENTRY 824 1148 38/53K :MAP 7 10 0/1K :VM OBJECT 66326 66406 6218/6225K :-- :TOTAL 58330/72146K : :So why is zalloc dying when it looks like only about 90 megs of :kernel memory is allocated? Are those active vnodes or cached vnodes? What is kern.maxvnodes set to? Also, what's the full vmstat -m output on the crash dump? :Anyhow, I've added a check in getnewvnode to return ENOMEM if zalloc :fails, my concern is that other parts of the kernel are going to :blow up immediately after that is caught because it looks like :the majority of places don't expect zalloc to fail. : :Any suggestions will be helpful, any requests for more information :will happily be attempted. : :thanks, :-Alfred Well, there's definitely some kind of limit being hit here. You have to figure out what it is first. Print out the zalloc zone structure being used to see why it is returning NULL. Maybe it has hit it's max count or something and the bug is that the zalloc zone isn't scaled with kern.maxvnodes, or something like that. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Can't newfs big filesystem (twe/4.3-stable)
:> newsfeed-inn# newfs -i 67108864 /dev/twed0d :> [stuff deleted] :> 1048576032, 1048641568, 1048707104, 1048772640, 1048838176, 1048903712, :> 1048969248, 1049034784, 1049100320, 1049165856, 1049231392, 1049296928, :> 1049362464, 1049428000, 1049493536, 1049559072, 1049624608, 1049690144, :> 1049755680, 1049821216, 1049886752, 1049952288, 1050017824, 1050083360, :> 1050148896, 1050214432, 1050279968, 1050345504, 1050411040, 1050476576, :> 1050542112, 1050607648, 1050673184, 1050738720, 1050804256, 1050869792, :> 1050935328 :> fsinit: inode value out of range (2). :> :> Tried larger -i parameters, same thing. :> :> Can't newfs figure this out before it gets to this point that something :> isn't going to work? :> :> I'll try some different block/frag sizes, see if it helps. Specifying a byte-to-inode ratio that large is kind of silly. I usually use something like -i 262144 -b 16384 -f 2048 on my larger filesystems. A couple of million would also probably work, but beyond that you aren't really saving anything, not even fsck time. I'm not surprised that 67 million doesn't work. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: The FreeBSD core team needs your help
:[jkh shows up in a british military uniform] : :OK, stop this at once, it's SILLY! cat /usr/share/examples/ibcs2/README | sed -e 's/.*l //' | sed -e 's/ t.*//' -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: time_t definition is worng
:On Fri, Jun 01, 2001 at 02:39:33PM +0300, Amir Shalem wrote:
:> it was always long int,
:> whenever you want to print time_t
:> in programs it was always
:> printf("%ld", (time_t)time);
:
:That cast is wrong; if you want to print a long, cast it to long.
:time_t is (was) only a long on the i386; on the alpha it was an int,
:and code which assumed it to be a long was unportable. It was changed
:to help catch exactly this kind of mistake.
:
:Kris
What, are you guys nuts? time_t is 64 bits on 64 bit platforms for
everyone except us? We may be screwed for 32 bit platforms, but don't
screw us on 64 bit platforms.
time_t should remain 'long' on IA32 (even though sizeof(int) ==
sizeof(long) on IA32), and it damn well should be 'long' on Alpha ...
the alpha guys should change it if it is currently an int on Alpha.
Please back out this commit. It is not appropriate to make time_t
an 'int' on IA32. time_t has been 'long' from time immemorial. This
is an unbelievably bad commit.
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-stable" in the body of the message
Re: adding "noschg" to ssh and friends
:I guess in general, that may be correct. But wouldn't you want some :reassurance that your only "secure" connection to the machine is not :tamered with? That is, if your machine is compromised, and the only :way you can connect to it is via a trojaned service, then you're :really hosed. I think ssh should be protected from this type of :attack. Well, lets see... what if someone modified /etc/ssh/config ? Or what if someone added a command= directive to your public key in ~/.ssh/authorized_keys ? Or what if someone modified pam (which ssh uses) ? Or what if someone changed the ldconfig path? etc etc etc. So the answer is no. :In any case, what about my other question? If I "schg" the ssh :related executables and libs, will installworld croak or does it know :to noschg all files first? I can't see that it does it even for the :binaries that are schg in the system already (like rsh). I've no idea on that one. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: FreeBSD and IPSEC
:I have two remote offices. I am running FreeBSD ver 4.0R on all three :firewalls. I would like to create two VPN between the remote offices and :our HQ here. I can create a VPN connection using the gif and :esp/tunnel//require, without the racoon, but from time to time the remote :offices loose communication with the HQ. If I allow routing between the :remote sites, without the VPN or encryption they work just fine. There are :some ipfw rules in place, but this happens even if I open the firewall up :all the way. : :Does anyone have any suggestions for troubleshooting this? Any ideas on :where to continue looking for problems? I'm not looking for answers(unless :you got them) I'm looking for the next place to look. : :Brandt Everett I did an IPSEC tunnel once with the same problem. It turned out that cyclic sequence numbers were not being allowed (I guess for security reasons). Any sort of packet loss caused the VPN to stop working. Allowing cyclic sequence numbers fixed the problem. Unfortunately, this was a year ago so I don't have the config file to show you. I'm not sure where you specify it in the config. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Continuing ahc problems - also cause fxp failure
This is getting weirder and weirder. 4.2 or 4.3-RC AHC failure once or twice a month (as previously posted last month) FXP Ethernet (appeared to be) working perfectly RELENG_4(After Justin's adaptec fix) FXP failure one week (old FXP driver) FXP failure the next week (old FXP driver) FXP *and* AHC failures tonight (new FXP driver) What I got tonight was basically a system lockup with the kernel generating console messages every few seconds from both the FXP and the AHC drivers. I *was* able to break into the debugger, but with ahc dead I couldn't generate a core. I think the system itself is fine and the problem is somewhere in the AHC or FXP drivers. I had failures with the old FXP driver as well as the new, and the old driver hasn't changed in months so the problem is either a PCI bug (cycle timer issues?) or there are still AHC bugs. Note the time. Not fun, but at least I managed to play with the console before someone else came in and rebooted the system :-) dmesg output is at the end. Here is what I was seeing on the console: fxp0: SCB timeout: 0xe0, 0, 0x90, 0x400 (other SCB timeout messages) fxp0: DMA timeout fxp0: command queue timeout fxp0: device timeout ... various repetitions ahc0: issued channel A bus reset, 4 SCB's aborted pci error interrupt at seqaddr 2 scb 0x40 timed out while IDLE seqaddr 0x181 stack 0x17e, e, e, e SXFRCTL0 = 0x80 Dumping card state: SCSISEQ = 0x12, SBLKCTL = 0xA, SSTAT0 = 0x0, SCB Count = 250 Kernel NEXTQSCB = 17 Card NEXTQSCB = 64 (I squiggled this down from the console so it is not an exact representation, but I think I got the meat). As I said, I was able to break into the debugger and apart from ahc and fxp being completely failed, nothing else was wrong. The failure occured during the nightly dump. The network was under a medium load (the backup is running over a T1) and the hard drives were probably under a heavy load. All previous failures seemed to have occured in the wee hours of the morning during our nightly dumps. The disks do not have an appreciable load during the day. -Matt Here is my dmesg output: Copyright (c) 1992-2001 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 4.3-STABLE #2: Fri May 18 11:36:08 PDT 2001 [EMAIL PROTECTED]:/usr/src/sys/compile/EARTH Timecounter "i8254" frequency 1193182 Hz CPU: Pentium III/Pentium III Xeon/Celeron (531.65-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x681 Stepping = 1 Features=0x383fbff real memory = 536862720 (524280K bytes) avail memory = 519012352 (506848K bytes) Preloaded elf kernel "kernel" at 0xc035. Pentium Pro MTRR support enabled md0: Malloc disk npx0: on motherboard npx0: INT 16 interface pcib0: on motherboard pci0: on pcib0 pcib1: at device 2.0 on pci0 pci1: on pcib1 ahc0: port 0xfc00-0xfcff mem 0xfcfff000-0xfcff irq 14 at device 4.0 on pci1 aic7890/91: Wide Channel A, SCSI Id=7, 32/255 SCBs ahc1: port 0xf800-0xf8ff mem 0xfcffe000-0xfcffefff irq 10 at device 6.0 on pci1 aic7880: Single Channel A, SCSI Id=7, 16/255 SCBs fxp0: port 0xecc0-0xecff mem 0xfe00-0xfe0f,0xfe101000-0xfe101fff irq 11 at device 8.0 on pci0 fxp0: Ethernet address 00:b0:d0:22:fb:03 inphy0: on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto pci0: at 14.0 isab0: at device 15.0 on pci0 isa0: on isab0 pcib2: on motherboard pci2: on pcib2 fxp1: port 0xdcc0-0xdcff mem 0xf610-0xf61f,0xf6201000-0xf6201fff irq 5 at device 6.0 on pci2 fxp1: Ethernet address 00:d0:b7:7e:75:c3 inphy1: on miibus1 inphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp2: port 0xdc80-0xdcbf mem 0xf600-0xf60f,0xf620-0xf6200fff irq 14 at device 8.0 on pci2 fxp2: Ethernet address 00:d0:b7:7e:77:31 inphy2: on miibus2 inphy2: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fdc0: at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> on fdc0 drive 0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0 sc0: on isa0 sc0: VGA <16 virtual consoles, flags=0x200> sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A IP packet filtering initialized, divert enabled, rule-based forwarding enabled, default to deny, logging disabled IPsec: Initialized Security Association Processing. IP Filter: v3.4.16 initialized. Default = pass all, Logging = disabled Waiting 5 seconds for SCSI devices to settle pass4 at
Re: Tagged Queueing and ATA driver (was soft update should be default)
Gee, maybe in another few years IDE will have implement the *entire* SCSI command set! Now wouldn't that be progress! Not! You will never see me turn on tagged queueing for IDE. If performance is an issue, SCSI is the solution. I want my data cooked over-easy thank you very much, not scrambled! -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Mem Use
:Don't think that's true for textfiles. : :I rmeember older *NIXes loaded processes off disk by causing :a page fault to read in the binary. I imagine FreeBSD does soemthing similar, : :The pageins you'd see running cat or more are probably /bin/cat and :/usr/bin/more being loaded. FreeBSD does demand-page executables, but if the data is already in the VM page cache then FreeBSD will pre-map some of the pages when you exec the program as an optimization -- so no (or fewer) faults will occur for those pages. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Mem Use
:>> My systems look very much like this also. Do note that there is 87 :>> MB free and 1 MB that some time in the past got swapped out. :> :>That's 87MB of totally unused memory, ie. wasted money. 8) : :Exactly. And it also slows down other disk I/O. Why doesn't it swap :it back in and leave it? It keeps bringing it back in every couple :seconds. I don't see any swap out activity, only lots of swapin. :... :-- :-- Doug If you are seeing swapin activity but no swapout activity it is typically due to a program that is randomly accessing a large memory address space slowly. 'named' is a really good example of this. The program is accessing the address space slowly enough that system pressures cause the system to reuse the memory at around the same rate -- giving it to other processes that need it more. The system will always allocate free memory before anything else, so if you have 87MB of free memory it's probably transient (that is, you are doing other things in your system that eat up the memory temporarily, then exit and free it all). Having free memory will not prevent swapins from occuring, but if you do not have a transient load that is causing large portions of memory to be freed then the swapin activity *will* slowly use up the free memory. swapin activity that is less then 100KB/sec will not have any appreciable effect on disk performance. In general swapin activity of any kind does not have nearly the effect that swapout activity has. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Should /sys/i386/conf/GENERIC's SysV shared memory settings+defaults be re-thought?
:.. :> while now, on a Pentium 166Mhz with 32M but around 100-150Mb or swap. :> :> Never had problems with SHM. : :i've commented about the problems with shm and a heavy enlightenment / :gnome load a few weeks ago to stable, but my message was pretty much :ignored. also note that this issue has been brought up in current a :year or so ago. : :my problems went away with: : : options SHMMAXPGS=8192 : options SHMMNI=4096 : options SHMSEG=1024 : :i don't know enough about the internals to know the downside for using :these high values, but i'm pretty confident on today's architectures :... : :david In general there is no downside. Shared memory is swap-backed (though the in-kernel control structures are not). I think it's high time that the system defaults be raised. I'll do it later today. You should also be able to raise the defaults using appropriate sysctl's, e.g.: sysctl -a | fgrep kern.ipc sysctl -w kern.ipc.shmmax=33554432 And, of course, with kernel conf variables. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Mem Use
:All this talk of memory utilisation reminds me to ask, are there any :plans to implement directio (Solaris UFS and VxFS have it)? There has been talk. It's considered 'interesting' but it is not a priority. FreeBSD's heuristics already handle write-behind and free-behind operations so, for example, writing out a 200MB file sequentially will not blow away your cache. :Any plans to implement priority paging, e.g. not cache files in memory :when memory is tight to reduce demand for paging? The VM system already tunes itself to load. It's not as simple as deciding whether to cache something or not... *everything* in the system is part of the cache. It's a matter of balancing demand and determining when to lunder dirty pages to their backing store. Anything that isn't dirty is potentially freeable whether it represents (cached) files, code, data, or anonymous memory. But gratuitously throwing away file cache pages will kill performance as quickly as gratuitously throwing away swapped out anonymous memory. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Strange BTX halted error
:... :> dangerously dedicated partitions. It's what prompted me to fix the :> disklabel code to allow boot blocks to be installed on slices. :> Unfortunately, the only way I could fix my particular problem was :> to get rid of my dangerously dedicated partition which meant blowing :> away the hard drive and repartitioning and relabeling it. : :If disk is `dangerously dedicated', sector 0:0:1 is occupied with boot1, :which does not use master PT area (0x1BE-0x1FF) and even contains :a simple fake valid PT. Did you ever try to set there something syntactically :valid for your BIOS and enough to allow loading of specific "bootloader"? :If you did, what was the problem? Yah, I tried that... didn't work. What did work was blowing away (zeroing) the beginning of the disk and then re-partitioning it from scratch using a real DOS disk partition and boot0 (using fdisk -BI), and installing boot1 and boot2 on the FreeBSD slice with disklabel's new ability to install boot sectors on slices, using 'disklabel -w -r -B da0s1 auto'. That worked. I incorporated the sequence into the disklabel manual page near the end of the EXAMPLES section. :P.S. On our FreeBSD hosts bunch we almost proved practically that the :only safe partitioning is to create DOS slices (with below-cyl-1024 :bootable one) with LBA geometry specified to fdisk. Any another approach :leads to something strange effects: e.g. BTX cannot load /boot/loader :and loads kernel directly, with natural `nlist failed'. But we never :tried to change fake PT on dedicated disk directly. : :/netch I haven't had to do that. Yet. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Strange BTX halted error
:The very last example, just before the SEE ALSO section for the :'disklabel' manual page shows how to do this. But be warned: it blows :away the disk. : : :http://www.FreeBSD.org/cgi/man.cgi?query=disklabel&apropos=0&sektion=0&manpath=FreeBSD+4.3-RELEASE&format=html : opps, in the above manual page it is the example-before-last. In the 4.x manual page it is the last example. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Strange BTX halted error
:Well, that's not going to work, as I don't have an Adaptec and I need the :onboard SCSI to boot =/ Thanks for the help though. If someone can :decipher what all the register's mean, I can provide access to the boot :loader binary and source (4.1.1-RELEASE I believe). : :-gordon : :On Tue, 1 May 2001 [EMAIL PROTECTED] wrote: : :> I had the exact same problem when I had 'SCSI Bios' enabled on my :> Adaptec 2940. :> :> Turned it off and that stopped. Not sure what the problem is, but I :> know that is the solution for me :) I was getting BTX halted failures due to BIOS confusion related to dangerously dedicated partitions. It's what prompted me to fix the disklabel code to allow boot blocks to be installed on slices. Unfortunately, the only way I could fix my particular problem was to get rid of my dangerously dedicated partition which meant blowing away the hard drive and repartitioning and relabeling it. The very last example, just before the SEE ALSO section for the 'disklabel' manual page shows how to do this. But be warned: it blows away the disk. http://www.FreeBSD.org/cgi/man.cgi?query=disklabel&apropos=0&sektion=0&manpath=FreeBSD+4.3-RELEASE&format=html I do not know if my problem is the same as yours, so this could be all for nothing. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Runt packets
:I have a dual-homed machine doing routing and firewalling on which hundreds
:of the following messages appear in my logs every 10 minutes or so:
:
: /kernel: icmp-response bandwidth limit 44069/200 pps
: /kernel: arp: runt packet
: last message repeated 14691 times
:
:At the same time these messages are occurring, I find the following while
:doing a tcpdump on the internal interface (it doesn't happen on the
:external interface at all):
:
: 19:05:34.247543 arp-#12469 for proto #208 (166) hardware #1 (183)
: 19:05:34.247588 arp-#12469 for proto #208 (166) hardware #1 (183)
: 19:05:34.247630 arp-#12469 for proto #208 (166) hardware #1 (183)
: 19:05:34.247674 arp-#12469 for proto #208 (166) hardware #1 (183)
: 19:05:34.247718 arp-#12469 for proto #208 (166) hardware #1 (183)
: 19:05:34.247762 arp-#12469 for proto #208 (166) hardware #1 (183)
: 19:05:34.247805 arp-#12469 for proto #208 (166) hardware #1 (183)
:
:...except there are thousands of these. Has anybody seen this before?
:I'm running a slightly old version of 4.2 (Thu Dec 14 15:28:03 EST 2000),
:but I didn't see any relevant diffs to sys/netinet/if_ether.c which is
:where the "runt packet" errors are sent to syslog. Could this be a problem
:of bad hardware on the part of one of the internal hosts?
:
:Any and all help is much appreciated.
:
:Thanks!
:Erick
A runt packet is typically caused by a collision on an ethernet segment.
There are lots of possibilities, but the jist is that if your network
is misconfigured you can wind up with a 'packet storm' of activity
due to competing machines constantly tripping over each other trying to
retransmit (usually large) packets.
Runt packets typically cannot pass through routers, but they can pass
throug hubs and can also often pass through switches (depending on the
method the switch uses to switch packets).
Here are some possibilities:
* You have a bad switch in your network somewhere nearby that is
allowing runt packets to be passed through and someone on some
other nearby LAN (connected to you through the switch) is broken.
* You have too many hubs and/or too-long ethernet segments in your
network somewhere nearby.
* There is a misconfigured host on the network. For example, a
host that is configured for full duplex in a half duplex network
will happily blast packets down the wire and cause everyone
else to retry continuously ('packet storm') while it is doing it.
Your problem kinda sounds like #3, but I don't your topology. The
easiest solution is take a small store-and-forward switch and insert
inline with segments of your network until you can isolate the problem
source. Any modern cheap 10/100 switch should do the job.
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-stable" in the body of the message
Re: NFS performance
:Actually, from what I've been told, TCP allows for much larger requests :than what UDP does, afaik UDP maxes out at 8k while tcp should be able :to go to 32k (maybe 64k) and give possibly better performance. : :Plus each time you 'hickup' under a UDP mount it's a lot more painful :because since it's possible for each RPC to be broken into several :packets you have a lot more retransmition to do. Depends on what kind of LAN you have. A standard 100BaseT network still has a 1536 byte packet size limit, so even 8K UDP NFS packets will be fragmented. The fragmentation is avoided with TCP, even though as many packets will be sent. This is why TCP mounts tend to have very comparable performance to UDP mounts. Under very heavily loaded conditions TCP could very well be the better choice because the TCP layer handles load a whole lot better then the NFS udp/timeout/retry layer and the kernel isn't really tuned to deal with hundreds of clients all sending fragmented packets at the same time. I wouldn't bother with larger NFS block sizes, even over TCP, unless you are running a much faster LAN (e.g. gigabit). -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: NFS performance
Putting on my NFS hat... I would not recommend NFSv2 to anyone. Everyone should be using NFSv3 at this point. It just does a much better job at everything, including and most especially at writing. TCP mounts are useful, and much safer, if you need to export NFS across a firewall. Otherwise I'd recommend sticking with UDP. -Matt :On Tue, 20 Mar 2001, Jan Conrad wrote: : :> We're making plans to upgrade our NFS server to FreeBSD-4.3 (including :> new disks...) and I would like to ask about the status of NFS v3? : :Why do you need NFSv3? Are there particular features in NFSv3 that you :need or are you just guessing that v2 > v3 and therefore better? : :> Currently, a standard NFS mount (4.3BETA) gives us a sequential writing :> speed of approx. 2Mb/s (just 400Mb dd'd data, IBM DTLA-307045 with :> softupdates) and reading speed of 9Mb/s (the maximum). : :What is the speed of your network? : :> Mounting via TCP gives us 2.5Mb/s. (Is this safe?) : :Why are you using TCP? If you are on a reliable LAN, use UDP. TCP should :be used for long haul NFS. There are lots of reasons for using UDP, if you :want me to go into them, I will. : :> Are there any other possibilities to increase the writing speed (by means :> of tuning NFS...)? : :Again, try UDP. Also, go pick up the O'Reilly book on NFS and NIS. Alot of :what I'm going to tell you is in there (indeed the book is on my desk at :work). : :-gordon To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Not only ftpd's problem with ls */../*.....
Ultimately the only thing I care about is that we not arbitrarily limit a global libc function by default, so I don't care which solution is adopted (api call, structural flag/field, resource limit) as long as the default for glob() is left unlimited. There are advantages and disadvantages to using the datasize resource limit or an API call / structural field inside ftpd to limit the glob function. The biggest advantage of the datasize resource limit is that it is under the ultimate control of the sysad and requires no changes to the system at all (other then backing out the glob commit). The disadvantage is that our current installworld process will not update inetd.conf autoamtically, so most of our target audience won't get the fix. The advantage of an API call / structure field is that we can build a reasonable limit into ftpd (and only ftpd), so our target audience gets the fix as the default, but now we have to provide an additional option to ftpd to set (or entirely remove) the limit to give sysads the ability to adjust it. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Not only ftpd's problem with ls */../*.....
:Yes, I'm considering the following: : : gl_flags |= GLOB_MAXFILES : gl_match = filemax : :Since gl_match is only used as an input parameter at the moment. :Another approach is to limit the number of bytes returned to ARG_MAX, :but I somewhat dislike that; it makes more sense to me to specify the :number of paths instead. :-- :Jonathan Hmm. Well, I like the idea of adding a flag to glob_t->flags but I would prefer not to add another element to the glob_t structure that would make it incompatible with existing programs. Remember the mess changing FILE caused. How about a combination of glob_t->flags and a global limit that can be set with a new api call, setgloblimit()? Or perhaps even just have the setgloblimit() API call and don't even bother with a new flag. int setgloblimit(int) Set the maximum number of (bytes? entries?) that will be allocated to fullfill a globing call. The previous setting is returned. A value of -1 indicates unlimited. The default is unlimited. Just having a plain old setgloblimit() call with nothing else (no flags, etc...) would be the most compatible solution. Remember when csh had an arbitrarily limit on command line length? Things like 'foreach i ( `find . -type f` )' would fail arbitrarily. Tcsh fixed that problem. Whatever we do, we do not want to reintroduce this same sort of problem in other programs (whether shells do their own globing or not). -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Continued panics on a recent STABLE machine
Try to get a core guys (& keep a copy of the kernel.debug). It looks like it should be possible to get a core. My guess is someone broke something associated with mbuf handling. The virtual address is completely and utterly bogus. -Matt : : :OK, I feel like I am cursed. I tried with a plain old RealTek, and the same :type of panic : :Fatal trap 12: page fault while in kernel mode :fault virtual address = 0xdcc03e00 :fault code = supervisor read, page not present :instruction pointer = 0x8:0xc0205980 :stack pointer = 0x10:0xc02a9e20 :frame pointer = 0x10:0xc02a9e2c :code segment= base 0x0, limit 0xf, type 0x1b : = DPL 0, pres 1, def32 1, gran 1 :processor eflags= interrupt enabled, resume, IOPL = 0 :current process = Idle :interrupt mask = net tty :kernel: type 12 trap, code=0 :Stopped at rl_encap+0x78: movl0(%edx),%eax : : : : :Mike Tancsa, tel +1 519 651 3400 :Network Administration, [EMAIL PROTECTED] :Sentex Communicationswww.sentex.net :Cambridge, Ontario Canadawww.sentex.net/mike : : :To Unsubscribe: send mail to [EMAIL PROTECTED] :with "unsubscribe freebsd-stable" in the body of the message : To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Installing the world on remote machines (was Re: Re[2]: KERNCONF instead of KERNEL?)
It's perfectly safe to do an installworld on a multi-user system providing: (1) That you've kicked any other users off and (2) That you've killed any daemons that might exec something on a regular basis. sendmail, cron, webserver, etc... (not sshd, but make sure nobody ssh's in while you are updating the source base). The issue here is that the installworld does not use a 'create file under temporary name and rename it' scheme. It uses a 'remove the old file, create the new file' scheme so an exec() at the wrong time can cause a program to try to load a partially written shared library (e.g. libc). Some daemons really take exception to this and wind up getting into fork/exec/core loops which can make the machine unusable. -- I always update my remote machines by building all necessary kernels, building the world, and installing it all on a build machine first to make sure I've got the upgrade procedure down. Then I NFS-export /usr/src and /usr/obj read-only to the remote machines and do the kernel install and the installworld on each remote machine. (note: /usr/src and /usr/obj should be part of the /usr partition, without using any softlink tricks, or running installworld on the remote machines will not work as expected). I never build the world directly on a remote machine. NOTE DANGER!!! When doing an installworld over NFS, it takes much longer for the installworld to copy any given file (such as files in /usr/lib), which increases the chance of a daemon trying to fork/exec a program and dying a horrible death, possibly making the machine unusable. All remote machines should have some sort of serial console and power cycler setup to allow recovery from these and other potential problems. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: cvsup confusion
I just do this every night. A 'crontab -e' as root suffices to install the entries. I've never found the need to create a custom cvsup file, the one in examples works just fine. The log level will list edits cvsup makes. 42 3 * * * /usr/local/bin/cvsup -g -L 2 -h cvsup2.freebsd.org /usr/share/examples/cvsup/ports-supfile 42 5 * * * /usr/local/bin/cvsup -g -L 2 -h cvsup2.freebsd.org /usr/share/examples/cvsup/stable-supfile No muss, no fuss. Works great over a modem once you've synced up. Alternatively, if I'm tracking the CVS tree: 42 4 * * * /usr/local/bin/cvsup -g -r 20 -L 2 -h cvsup.freebsd.org /usr/share/examples/cvsup/cvs-supfile -- In regards to /etc/periodic... no, it is not a good idea to put a default cvsup in there. A good chunk of installations don't need to run it.. for example, for Backplane (and for BEST, and for home as well), I have one machine doing the cvsup's and then I export /usr/src and /usr/obj to the others read-only, allowing me to buildworld on the one machine and then installworld on all the others. It works unbelivably well. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: RE: Proposed makewhatis perl script fix
From the signal() manual page: When a process which has installed signal handlers forks, the child pro- cess inherits the signals. All caught signals may be reset to their de- fault action by a call to the execve(2) function; ignored signals remain ignored. So I would say that it is definitely ssh that is changing the SIGPIPE methodology. gunzip must be exiting without generating an error message with SIGPIPE is SIG_DFL. If gunzip were ever to catch the signal and report it, though, we will wind up with the errors popping up again, even if we fix ssh. For now I think ssh should be fixed. -Matt :On Sunday, February 11, 2001 03:41:48 -0500, Barney Wolff :<[EMAIL PROTECTED]> wrote: :+- :| Er, could it possibly be that telnet has been hiding the error :| all along? It's really, really hard to see how ssh could :| *create* this sort of error. :+--->8 : :Someone mentioned earlier that sshd seemed to be setting SIGPIPE to SIG_IGN :in the child shell; that would lead to subprocesses getting EPIPE instead :of SIGPIPE, and typically the application reports the former and tar's :parent the latter, so the new error behavior would be expected. : :-- :brandon s. allbery [os/2][linux][solaris][japh] [EMAIL PROTECTED] :system administrator[WAY too many hats] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: installworld anomoly
:Secondly, making makewhatis(1) read all available input before closing :the pipe is just unnecessarily slowing down makewhatis. There's no :reason for makewhatis to process an entire man page - it just needs the :... :Peter You won't notice much difference in times (time it and see for yourself!). On my system, the difference is about 1.6 seconds (5.26 verses 6.75). Considering that the disk cache makes a difference of 3+ seconds (9.96 -> 6.75), it just isn't a big deal. It is reasonable for makewhatis to drain the entire contents of the man page fed to it from whatever source, whether it uses the entire input or not. Trying to 'fix' the size of the pipe to avoid the problem isn't a good solution. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Proposed makewhatis perl script fix
The makewhatis patch has been committed to -current and will be MFC'd to -stable on tuesday. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Proposed makewhatis perl script fix
This should fix the installworld problems. I'll commit it to -current
tonight and MFC it in two days unless people find something wrong with
it. It would be nice if someone else could test it first.
-Matt
Index: makewhatis.perl
===
RCS file: /home/ncvs/src/gnu/usr.bin/man/makewhatis/makewhatis.perl,v
retrieving revision 1.21
diff -u -r1.21 makewhatis.perl
--- makewhatis.perl 1999/09/11 18:21:16 1.21
+++ makewhatis.perl 2001/02/04 21:11:34
@@ -352,6 +352,7 @@
$list .= ' ';
}
}
+ while() { } # skip remaining input to avoid pipe errors
&out($list); close F; return 1;
} elsif (/^\.Sh/ && /^\.Sh[ \t]+["]?($section_name)["]?/) {
# ``doc'' style pages
@@ -375,9 +376,11 @@
$list .= ' ';
}
}
+ while() { } # skip remaining input to avoid pipe errors
&out($list); close F; return 1;
} elsif(/^\.so/ && /^\.so[ \t]+man/) {
+ while() { } # skip remaining input to avoid pipe errors
close F; return 1;
}
}
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-stable" in the body of the message
Re: installworld anomoly
:--ibTvN161/egqYuK8 :Content-Type: text/plain; charset=us-ascii :Content-Disposition: inline : :On Sat, Feb 03, 2001 at 03:43:44PM -0500, Brian Dean wrote: : :> Is anyone else seeing this? : :Yes, it's a known bug in OpenSSH. There's a patch in the PR database, :I don't have the number handy, and haven't tried it myself. : :Kris It's not a bug with OpenSSH, it's a bug with 'makewhatis'. The 'makewhatis' perl script is closing the input descriptor without draining all the input. If the gzcat writing the descriptor does not use a large enough buffer, the gzcat's write() will then fail. This is not a bug with gzcat or a bug due to the pipe being too small (there is no 'right' size for the pipe), it's a bug with 'makewhatis', and a very easy bug to fix too. Since other people are reporting this (I reported this problem in early January), I'll go ahead and fix the perl script. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: [NFS] Incompatible: FreeBSD 4.2 client, Linux 2.2.18 nfsv3 server, read-only export
: :On Wed, Jan 24, 2001 at 10:28:02AM -0800, Matt Dillon wrote: :> This particular problem, however, is entirely Linux's problem to fix. : :Umm, could somebody *PLEASE* show me *ANY* place where I argued that it :wasn't a Linux bug? I can show at least one mail message where I :said it *WAS* a Linux bug : :(Heck, are there any places where *anybody* argued that this wasn't a :Linux bug?) I didn't mean to say that someone argued it wasn't :-). I'm just saying that in the world of interoperability, it may actually be more of a problem hacking a solution into the FreeBSD client side then waiting for a solution on the Linux side. Even though a FreeBSD hack could be made to work, introducing that sort of pollution into the client code will only make interoperability testing between various systems (Linux, FreeBSD, solaris, NetApp, HPUX, and a host of other systems) more difficult and less definitive. NFSv3 is an industry standard today mainly because vendors have worked hard towards fixing interoperability problems, and one of the things that makes this possible is to enforce error reporting & failure conditions on the client-side. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: [NFS] Incompatible: FreeBSD 4.2 client, Linux 2.2.18 nfsv3 server, read-only export
All this discussion over the right way to do ACCESS is moot. The NFSv3 protocol docs are absolutely clear on how ACCESS is supposed to work, and if Linux wants to be NFSv3 interoperable it has to follow the protocol. The FreeBSD client is following the protocol properly... it just happens to use more of the documented protocol then Solaris does, to good effect I might add. Over the last few years ocassional protocol bugs have cropped up in FreeBSD - and we've fixed them. For example, we weren't handling O_EXCL file creation under NFSv3 properly (just recently fixed in the last two months), and this caused solaris clients in default configurations to error out on files created with O_EXCL from FreeBSD clients. An example of a bug the other way around -- Solaris clients don't handle directory scan restarts properly. It turned out that the FreeBSD server could relax a certain error return (two lines of code) to fix solaris clients, while still keeping within protocol parameters. We did that in the name of interoperability because it was trivial and didn't impact performance. Because of this work, FreeBSD's NFSv3 implementation is interoperable with just about everything else out there. It's rep is well deserved. This particular problem, however, is entirely Linux's problem to fix. We are not going to rewrite our properly implemented access cache in order to workaround a linux NFSv3 server bug that can be fixed trivially in Linux. You don't have to like the NFSv3 protocol spec -- heavens knows there are big pieces of it that I don't like. But you do have to follow it if you want interoperability with non-Linux NFS servers. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: RE: Weird sporadic DNS resolution problems
: :At 11:48 AM 1/19/01 -0800, Matt Dillon wrote: : :> Don't do that! :> :> If the broken hosts have at least one working name server, then you :> can use options in named.conf to make bind ignore the broken servers. :> The bind documentation has all the information you need to make this :> work. This is a whole lot safer then creating static entries in :> /etc/hosts. : :Are you referring to auth-nxdomain ? Or something else ? : : ---Mike Let me find it... ah, here, look at the 'server' option. file:/usr/share/doc/bind/html/server.html And also the 'blackhole' option: file:/usr/share/doc/bind/html/options.html -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: RE: Weird sporadic DNS resolution problems
:Short term, though, I liked the suggestion about stuffing an entry in :/etc/hosts to work around the broken domains' DNS problems, and that does :work for me for now. So at least I have an ugly workaround.. much less :ugly than restarted named every few hours though. Next, I'm going to :start comparing the sendmail.cf files built from my old 8.9.3 .mc file and :my current 8.11.x .mc file and see if any big differences jump out at :me... : :Mike Andrews * [EMAIL PROTECTED] * [EMAIL PROTECTED] * http://www.bit0.com Don't do that! If the broken hosts have at least one working name server, then you can use options in named.conf to make bind ignore the broken servers. The bind documentation has all the information you need to make this work. This is a whole lot safer then creating static entries in /etc/hosts. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: /swap too large? What??
: Hi gang, : : Okay, I have downloaded 4.2, from January 10 or so. I have : a ~1.7GB swap defined on da0s1b. When I attempt to mount it, : however, I am told: : :exceeded maximum of 3355443 blocks per swap unit : : Hmmm. I can't find anything about this in the archives, nor am : I able to: The only thing that can cause this is if you have configured an absurdly large NSWAPDEV. : I am concerned, however, as to why I can't mount my previous : swap area on a different disk. Has something changed to limit the : swap space you can create? : : Bruce A sanity check was put in the code to ensure that the internal bitmap tree could not overflow. The default NSWAPDEV is 4 (up to 4 swap devices). The block limitation is (2GB / 16 / NSWAPDEV) 512 byte blocks, or: 2GB / 16 / NSWAPDEV * 512. If NSWAPPDEV is 4, each swap parition can theoretically be up to 17 GB in size. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Repeated panic in 4.2-stable
( I think -stable will be interested in this so I'm including -stable in the thread ) --> TO EVERYONE RUNNING STABLE!!! Do not use a filesystem block size greater then 16384. 8192 is ok, 16384 should be ok. Anything bigger will hit this bug. :Yes. PR 20609, assigned to you for some time. : :> The buffer map is a system map, right? Which means it allocates :> map_entry elements out of kmapentzone, which is a ZONE_INTERRUPT zone, :> which can't block. : :No. It is not a system map. It should be a system map. : :> There is a vm_object_allocate() call, which uses a non-interrupt zone, :> but I don't think it applies to buffer-cache buffers. Buffer cache :> buffer KVM is not backed by arbitrary VM objects. : :_vm_map_clip_end() and _vm_map_clip_start() calls vm_object_allocate() :if the entry being split has no object. So it certainly applies to :the buffer cache buffers due to vm objects incorrectly being allocated :for buffer map entries. : :- Tor Egge Yes, well, there are two dozen PR's assigned to me... sometimes I loose track :-) Grr. You know what Tor, your mail from middle of last year is *still* in my inbox! Ok, I'll look into it and not forget this time. The patch you include in the PR seems reasonable after a quick look. The VFS/BIO subsystem never calls vm_map_simplify_entry() or vm_map_lookup(), which means that as long as the filesystem block size does not exceed the buffer cache KVM granularity the clipping routines will never be called. The buffer cache KVM granularity is 16384 bytes. So as long as one does not use a block size greater then 16384 bytes it should be reasonably safe (we still have to fix this, of course, I'm trying to diagnose the likelyhood of a problem for people using standard block sizes). A block size of exactly 16384 bytes should work fine. It looks like with the above stricture, the only exposed hole is the vm_map_entry allocation routine. If we block there it is possible for a second entry in the VFS/BIO subsystem to allocate the same KVM address range and create a second buffer sharing the same backing memory. (Side note: If bitmap blocks exceed 16384K, this could cause serious filesystem corruption. I'm not sure whether this is possible or not but it's something to think about. It could be related to why filesystems with extreme newfs parameters seems to have more then their fair share of problems). I will say that of course we have to fix this bug, but in the current released systems there is virtually no chance of zalloc() blocking due to the low memory deadlock fixes I put in after christmas. So as long as people are not using a filesystem block size larger then 16384 bytes I think their systems will be fine. This is a great example of how fragile code can wind up in a relatively stable system with no alarm bells ringing. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
NFSv3 O_EXCL file create - protocol spec & solution (was Re: Bug in NFSv3 client)
The RFC (1813) says that the exclusive-file-create NFS op passes a
verifier. It says, and I quote:
"One aspect of the NFS version 3 protocol CREATE procedure
warrants particularly careful consideration: the mechanism
introduced to support the reliable exclusive creation of
regular files. The mechanism comes into play when how.mode
is EXCLUSIVE. In this case, how.verf contains a verifier
that can reasonably be expected to be unique. A
combination of a client identifier, perhaps the client
network address, and a unique number generated by the
client, perhaps the RPC transaction identifier, may be
appropriate."
What that means is that the verifier can be anything.
Here's why the FreeBSD server was storing the verifier as the
file access time:
"verifier must be stored in stable storage to prevent
erroneous failure on retransmission of the request. It is
assumed that an exclusive create is being performed
because exclusive semantics are critical to the
application. Because of the expected usage, exclusive
CREATE does not rely solely on the normally volatile
duplicate request cache for storage of the verifier. The
duplicate request cache in volatile storage does not
survive a crash and may actually flush on a long network
partition, opening failure windows. In the UNIX local
file system environment, the expected storage location for
the verifier on creation is the metadata (time stamps) of
the file. For this reason, an exclusive file create may
not include initial attributes because the server would
have nowhere to store the verifier."
Ahhh, so now we know why FreeBSD is passing the IP address of
the interface plus a 'unique' number! Or trying anyway.
And also:
"Once the client has performed a successful exclusive
create, it must issue a SETATTR to set the correct file
attributes. Until it does so, it should not rely upon any
of the file attributes, since the server implementation
may need to overload file metadata to store the verifier."
What this means is that the FreeBSD client is supposed to call
SETATTR to set the correct file attributes after the O_EXCL open
succeeds. It is in fact doing this, but the 'atime' attribute
in the 'vap' structure is not initialized, so the SETATTR call
never actually fixes up the access time.
Solaris probably shouldn't be generating an error for the 'bogus'
time specification, as that can race with an O_EXCL create, but
I think fixing the FreeBSD clients to do the proper SETATTR
should solve the problem.
I've included the patch below. The patch will fix FreeBSD
clients. I will commit it to -current now and to -stable in
two days if there aren't any problems. (Throw away any previous
patches you might have applied).
-Matt
Index: nfs_vnops.c
===
RCS file: /home/ncvs/src/sys/nfs/nfs_vnops.c,v
retrieving revision 1.150
diff -u -r1.150 nfs_vnops.c
--- nfs_vnops.c 2000/01/05 00:32:18 1.150
+++ nfs_vnops.c 2001/01/04 07:48:37
@@ -1436,8 +1436,21 @@
}
if (newvp)
vput(newvp);
- } else if (v3 && (fmode & O_EXCL))
+ } else if (v3 && (fmode & O_EXCL)) {
+ /*
+* We are normally called with only a partially initialized
+* VAP. Since the NFSv3 spec says that server may use the
+* file attributes to store the verifier, the spec requires
+* us to do a SETATTR RPC. FreeBSD servers store the verifier
+* in atime, but we can't really assume that all servers will
+* so we ensure that our SETATTR sets both atime and mtime.
+*/
+ if (vap->va_mtime.tv_sec == VNOVAL)
+ vfs_timestamp(&vap->va_mtime);
+ if (vap->va_atime.tv_sec == VNOVAL)
+ vap->va_atime = vap->va_mtime;
error = nfs_setattrrpc(newvp, vap, cnp->cn_cred, cnp->cn_proc);
+ }
if (!error) {
if (cnp->cn_flags & MAKEENTRY)
cache_enter(dvp, newvp, cnp);
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-stable" in the body of the message
Re: softupdates and "/"
: :So to keep Softupdates active on all boot ups, you have to re-execute :"tunefs -n enable /" or "tunefs -n enable /usr"? Otherwise its not active :on the partition? : :Jorge Once you turn softupdates on with tunefs, it's on for good. Of course, your kernel has to be compiled with the SOFTUPDATES option to actually run softupdates. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
New performance patch available for testing on stable
The URL: http://apollo.backplane.com/FreeBSD4/ This patch reworks the pageout daemon and the buf_daemon. It is based on my previous patch but hopefully has the kinks worked out. The patch is for -stable only, I will have a -current patch tonight. The main change is to the buf_daemon. I ripped out the dynamic speedup / slowdown code because it just wasn't working. I replaced it with code to track the amount of I/O in-progress in order to be able to limit the flush rate based on that. I also ripped out the non-working hysteresis for waking up the buf_daemon and put in real hysteresis, and I ripped out the artificial limitations on the number of buffers that could be flushed per wakeup (just like I ripped out the maxlaunder limitation in the pageout daemon in the last patch), and instead flush until the low water mark is reached, using the runningbufspace (bytes in transit to the I/O device) to limit the flush rate. In my testing, these changes lead to much, much smoother operation in heavily loaded situations and also appears to improve the write rate: 4.2-STABLE: (dd'ing to a CCD stripe of two SCSI drives) serv02:/data1# dd if=/dev/zero of=test bs=32k count=49152 49152+0 records in 49152+0 records out 1610612736 bytes transferred in 34.506011 secs (46676295 bytes/sec) 4.2-STABLE + patches: (dd'ing to a CCD stripe of two SCSI drives) serv01:/data1# dd if=/dev/zero of=test bs=32k count=49152 49152+0 records in 49152+0 records out 1610612736 bytes transferred in 27.995698 secs (57530722 bytes/sec) The current patchset will pageout a little more then 4.2-RELEASE, but hopefully to the benefit of the system rather then the detriment. This is because I ripped out the two-pass inactive queue scan in the pageout daemon that was skipping dirty pages in the first pass (giving them too much priority) and replaced it with a one-pass scan. I am slowly making my way to per-(disk)-device I/O pipelining. At the moment the pipelining is system-wide. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: VMware hanging
Ok (this to the -stable mailing list). Barry and I have figurd out
why VMWare was locking up on him.
We tracked it down to excessive dirty filesystem buffers, created
through this codepath:
Debugger(c02ca083) at Debugger+0x35
panic(c02cd684,ca77cbe8,c018054a,c4f9cdb8,c4f9cdb8) at panic+0x70
bdirty(c4f9cdb8,c4f9cdb8,cb719000,0,c1218800) at bdirty+0x5d
bdwrite(c4f9cdb8,cb719000,0,0,2000) at bdwrite+0x52
cluster_write(c4f9cdb8,676a000,0,0) at cluster_write+0x313
ffs_write(ca77ccf8) at ffs_write+0x48b
vnode_pager_generic_putpages(cb719000,ca77ce08,1,0,ca77cd9c) at
vnode_pager_generic_putpages+0x181
ffs_putpages(ca77cd60) at ffs_putpages+0x1f
vnode_pager_putpages(cb72dae0,ca77ce08,10,0,ca77cd9c) at vnode_pager_putpages+0x
6a
vm_pageout_flush(ca77ce08,10,0,0,c0ad7a7c) at vm_pageout_flush+0xb1
vm_object_page_clean(cb72dae0,0,0,4,0) at vm_object_page_clean+0x36a
vfs_msync(c11e5200,2,ca768600,0,ca76e780) at vfs_msync+0xc5
sync_fsync(ca77cf7c) at sync_fsync+0x4b
sched_sync(0) at sched_sync+0xf3
fork_trampoline() at fork_trampoline+0x8
The problem occurs when msync() tries to flush non-contiguous dirty
pages. There is a hole in cluster code that does not check for
excessive dirty buffers before issuing a bdwrite(), resulting in
excessive dirty buffers. Since the cluster code is rather sensitive,
my fix occurs at a higher level (in the UFS code).
The patch below appears to solve the problem for Barry. I will commit
it to -current now, and to -stable in 2 days. I've also committed a
patch to writev() to -current and will backport it to -stable in 2 days
as well.
-Matt
Index: ufs/ufs/ufs_readwrite.c
===
RCS file: /home/ncvs/src/sys/ufs/ufs/ufs_readwrite.c,v
retrieving revision 1.65.2.3
diff -u -r1.65.2.3 ufs_readwrite.c
--- ufs/ufs/ufs_readwrite.c 2000/11/26 02:55:13 1.65.2.3
+++ ufs/ufs/ufs_readwrite.c 2000/12/06 20:03:59
@@ -495,6 +495,9 @@
if (ioflag & IO_SYNC) {
(void)bwrite(bp);
+ } else if (vm_page_count_severe() || buf_dirty_count_severe()) {
+ bp->b_flags |= B_CLUSTEROK;
+ bawrite(bp);
} else if (xfersize + blkoffset == fs->fs_bsize) {
if ((vp->v_mount->mnt_flag & MNT_NOCLUSTERW) == 0) {
bp->b_flags |= B_CLUSTEROK;
@@ -502,9 +505,6 @@
} else {
bawrite(bp);
}
- } else if (vm_page_count_severe() || buf_dirty_count_severe()) {
- bp->b_flags |= B_CLUSTEROK;
- bawrite(bp);
} else {
bp->b_flags |= B_CLUSTEROK;
bdwrite(bp);
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-stable" in the body of the message
Re: Really odd "BTX halted" problem booting FreeBSD on VALinux h
:> # optional dd if you are paranoid :> # dd if=/dev/zero of=/dev/da0 bs=32k count=4 :> fdisk -I da0 :> disklabel -w -r da0s1 auto :> :> That's much preferable to having to use sysinstall if all you want to :> do is initialize a label on a slice. : :Yes, this is definitely the desired behavior. : :-- : :John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/ John, can you explain how the MBR bootstraps a slice? Should I make disklabel zero-out the fdisk partition table area in the slice rather then installing the dummy fdisk partition table? That is, for the case where -B is used on a slice (da0s1) verses on the whole-disk (da0)? -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Really odd "BTX halted" problem booting FreeBSD on VALinux h
:> I think you are specifying the wrong arguments to disklabel; I
:> seem to rememebr a -w/-W distinction...
:
:Nope.
:
:> In any case, I'm running with a disklabel inside a DOS partition
:> on all but one box of mine, and always have been. I installed
:> 4.1 on my laptop that way.
:
:Sysinstall can create a disklabel inside of a MBR slice fine. The
:problem is that the disklabel(8) _program_ itself doesn't know how
:to create a virgin disklabel for a MBR slice.
:
:--
:
:John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/
The patchset I put on the lists earlier today will allow disklabel
to install a virgin label on a slice. Did it not get out? As matters
currently stand, disklabel can only edit a preexisting label on a slice.
I'll post it again... included below (this time without the file
descriptor cruft that snuck into my previous posting of the patch). With
the patch you can do this:
# optional dd if you are paranoid
# dd if=/dev/zero of=/dev/da0 bs=32k count=4
fdisk -I da0
disklabel -w -r da0s1 auto
That's much preferable to having to use sysinstall if all you want to
do is initialize a label on a slice.
-Matt
Index: sbin/disklabel/disklabel.c
===
RCS file: /home/ncvs/src/sbin/disklabel/disklabel.c,v
retrieving revision 1.28.2.3
diff -u -r1.28.2.3 disklabel.c
--- sbin/disklabel/disklabel.c 2000/07/01 06:47:46 1.28.2.3
+++ sbin/disklabel/disklabel.c 2000/10/27 19:24:00
@@ -1347,10 +1347,17 @@
warn("cannot open %s", namebuf);
return (NULL);
}
- if (ioctl(f, DIOCGDINFO, &lab) < 0) {
- warn("ioctl DIOCGDINFO");
- close(f);
- return (NULL);
+
+ /*
+* Try to use the new get-virgin-label ioctl. If it fails,
+* fallback to the old get-disdk-info ioctl.
+*/
+ if (ioctl(f, DIOCGDVIRGIN, &lab) < 0) {
+ if (ioctl(f, DIOCGDINFO, &lab) < 0) {
+ warn("ioctl DIOCGDINFO");
+ close(f);
+ return (NULL);
+ }
}
close(f);
lab.d_boot0 = NULL;
Index: sys/kern/subr_diskslice.c
===
RCS file: /home/ncvs/src/sys/kern/subr_diskslice.c,v
retrieving revision 1.82
diff -u -r1.82 subr_diskslice.c
--- sys/kern/subr_diskslice.c 2000/01/28 11:51:08 1.82
+++ sys/kern/subr_diskslice.c 2000/10/27 19:23:28
@@ -366,12 +366,46 @@
int slice;
struct diskslice *sp;
struct diskslices *ssp;
+ struct partition *pp;
slice = dkslice(dev);
ssp = *sspp;
sp = &ssp->dss_slices[slice];
lp = sp->ds_label;
switch (cmd) {
+
+ case DIOCGDVIRGIN:
+ lp = (struct disklabel *)data;
+ if (ssp->dss_slices[WHOLE_DISK_SLICE].ds_label) {
+ *lp = *ssp->dss_slices[WHOLE_DISK_SLICE].ds_label;
+ } else {
+ bzero(lp, sizeof(struct disklabel));
+ }
+
+ lp->d_magic = DISKMAGIC;
+ lp->d_magic2 = DISKMAGIC;
+ pp = &lp->d_partitions[RAW_PART];
+ pp->p_offset = 0;
+ pp->p_size = sp->ds_size;
+
+ lp->d_npartitions = MAXPARTITIONS;
+ if (lp->d_interleave == 0)
+ lp->d_interleave = 1;
+ if (lp->d_rpm == 0)
+ lp->d_rpm = 3600;
+ if (lp->d_nsectors == 0)
+ lp->d_nsectors = 32;
+ if (lp->d_ntracks == 0)
+ lp->d_ntracks = 64;
+
+ lp->d_bbsize = BBSIZE;
+ lp->d_sbsize = SBSIZE;
+ lp->d_secpercyl = lp->d_nsectors * lp->d_ntracks;
+ lp->d_ncylinders = sp->ds_size / lp->d_secpercyl;
+ lp->d_secperunit = sp->ds_size;
+ lp->d_checksum = 0;
+ lp->d_checksum = dkcksum(lp);
+ return (0);
case DIOCGDINFO:
if (lp == NULL)
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-stable" in the body of the message
