Re: soft updates and qmail (RE: qmail IO problems)

[Tony Finch]

Greg Black <[EMAIL PROTECTED]> wrote:
>Tony Finch wrote:
>
>> Why not just use rename(2)? To protect against the new filename
>> already existing?
>
>Why not just read the man page for rename(2) before making
>suggestions?

I did. I'm glad I was right that it's deleting the destination that is
the problem. I would have thought it would be easy to be sure that
spool filenames are unique, but OTOH I guess that's not completely
robust.

Tony.
-- 
f.a.n.finch[EMAIL PROTECTED][EMAIL PROTECTED]
GERMAN BIGHT: SOUTHERLY BECOMING CYCLONIC THEN MAINLY NORTHERLY 5 TO 7,
PERHAPS GALE 8 LATER. RAIN. MAINLY MODERATE.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Kernel editing tools.

[Victor Ivanov]

On Wed, Feb 07, 2001 at 07:25:42PM -0500, Kevin Brunelle wrote:
> Hey everyone,
> 
> Sorry if you have heard this before, or if it is annoying. I just can't
> seem to find any information on this.
> 
> I have been poking around my kernel for quite some time now, and I have
> been doing it with various text editors and programs of that nature. It
> suddenly occured to me that there might be a better way to go about
> this. So I ask you, are there any programs that make reading and editing
> the kernel sources any easier? I was thinking about possibly writing a
> utility to do something like this, if one cannot be found. I don't
> pretend to be super skilled; I just want some honest advice. Surely you
> aren't all hacking away on vi or the *other* editor.
> 
> Well, thanks in advance for any help you can offer.

Look at FreeBSD Source Tour at http://current.jp.freebsd.org/. I think it's
great for browsing the source code.

-- 
Players win and Winners play
Have a lucky day

 PGP signature

Re: syscall kernel modules on 3.0-release

[Julian Elischer]

Matthew Emmerton wrote:
> 
> On 7 Feb 2001, Dag-Erling Smorgrav wrote:
> 
> > Matthew Luckie <[EMAIL PROTECTED]> writes:
> > > I completely understand your plea to not use 3.0 release.
> > > I am personally using 4.2-stable.  Its not my decision to use 3.0
> > > I beleive the computers running 3.0 have been running it for several years
> > > now - i.e. it was the latest available at the time.
> >
> > Well, it was a stupid decision at that time, and the decision not to
> > upgrade or replace these machines now is even stupider.
> 
> Hey now, go easy.  Lots of stupid decisions are made by "managers" who
> don't understand the implications of old(er) technology.
> 
> I've got a 3.2-R machine which I'm forced to maintain, and the only reason
> why it's not running 3.2-S or 4.2-S is because I can't take the stupid
> thing offline.  I've haggled with my boss for a 6 hour window and the
> answer is no, no, no.  I've even got a 3.2-S installation waiting in
> /usr/obj.

then you will need considerably less than 6 hours..
try asking for 25 minutes...
(is 3.2 enough?) you could go to 4.x by doing the compile remotely
and nfs mounting /usr/obj/ /usr/src and doing a make installworld from
there)


> 
> The only way I'm going to get my 3.2-R machine upgraded (and the only way
> this person is going to get their 3.0-R machine upgraded) is when it
> breaks and requires a complete reinstall to become operational.
> 
> --
> Matt Emmerton
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-hackers" in the body of the message

-- 
  __--_|\  Julian Elischer
 /   \ [EMAIL PROTECTED]
(   OZ) World tour 2000-2001
---> X_.---._/  
v


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: syscall kernel modules on 3.0-release

[Dag-Erling Smorgrav]

Matthew Emmerton <[EMAIL PROTECTED]> writes:
> I've got a 3.2-R machine which I'm forced to maintain, and the only reason
> why it's not running 3.2-S or 4.2-S is because I can't take the stupid
> thing offline.  I've haggled with my boss for a 6 hour window and the
> answer is no, no, no.  I've even got a 3.2-S installation waiting in
> /usr/obj.

You don't need a six-hour window. Take a level 0 dump of the box,
restore it on a scratch box, upgrade the scratch box and test it. If
you can, write a script that does the entire upgrade. When you're sure
you've got it down pat, take the production box down for however long
you need to upgrade it (somewhere between half an hour and two hours
depending on disk speeds and how much tinkering is needed).

DES (been there, done that)
-- 
Dag-Erling Smorgrav - [EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: vinum and qmail (RE: qmail IO problems)

[Julian Elischer]

Dan Phoenix wrote:
> 
> Yes maxusers stopped the dmesg errorsit seemed. Only thing I do not
> like to much about postfix is that it only tries one MX record and then
> does not try any others"default"yes there is still backlog with
> #'s I gave you. Right now 8 min to get an email from sending...I have
> another machine here still with qmail on itgoing to try to evenly
> distribute the mail between them and see how it goes. I cannot get you
> stats from linux box because i wiped it out with freebsdI will do
> everything in my power to keep this box freebsd. Why qmail and linux was
> handling the load I will never know now but regardless.with 600 megs
> being pushed a day with all that included backlog .how many megs do
> you think one ide drive can handle will be the biggest question to tackle
> over next few days.
>


So, after that last discussion here, did you turn on soft updates?

-- 
  __--_|\  Julian Elischer
 /   \ [EMAIL PROTECTED]
(   OZ) World tour 2000-2001
---> X_.---._/  
v


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: vinum and qmail (RE: qmail IO problems)

[Julian Elischer]

Matt Dillon wrote:
> 
> :Yes maxusers stopped the dmesg errorsit seemed. Only thing I do not
> :like to much about postfix is that it only tries one MX record and then
> :does not try any others"default"yes there is still backlog with
> :#'s I gave you. Right now 8 min to get an email from sending...I have
> :another machine here still with qmail on itgoing to try to evenly
> :distribute the mail between them and see how it goes. I cannot get you
> :stats from linux box because i wiped it out with freebsdI will do
> :everything in my power to keep this box freebsd. Why qmail and linux was
> :handling the load I will never know now but regardless.with 600 megs
> :being pushed a day with all that included backlog .how many megs do
> :you think one ide drive can handle will be the biggest question to tackle
> :over next few days.
> :
> :...
> :
> :Per-Hour Traffic Summary
> :time  received  delivered   deferredbounced rejected
> :
> :-01009788   9514373430  5
> :0100-02005800   5782374352  1
> :0200-03006438   6951553361  0
> :0300-0400   11497  10192591420  0
> :...
> :0800-0900   12691   9925922452  2
> :0900-1000   12174  12354   1205645  2
> :1000-1100   13884  10220837465  1
> 
> It looks like you are maxing out at 13000 or so emails per hour,
> which is 3.6 a second.
> 
> Well, that accounts for the disk activity :-)
iostat 1
would be interesting..

the linux equivalent would have been interesting too..


-- 
  __--_|\  Julian Elischer
 /   \ [EMAIL PROTECTED]
(   OZ) World tour 2000-2001
---> X_.---._/  
v


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

RE: syscall kernel modules on 3.0-release

[Koster, K.J.]

> 
> Hmm, I have exactly the same situation, a mission-critical server that
> can't be taken offline to do an upgrade. It's running 3.4, 
> but with a few binaries from 4.0 that I needed to make our CGIs work 
> (development is done on 4.2 :).
>
Euh... Mission Critical(tm) without a backup machine? Your boss did sign the
"will not whine when it dies"--agreement, right?

Kees Jan


 You are only young once,
   but you can stay immature all your life.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: What's changed recently with vmware/linuxemu/file I/O

[Josef Karthauser]

On Wed, Feb 07, 2001 at 10:07:06PM -0500, Robert Watson wrote:
> 
> On 7 Feb 2001, Dag-Erling Smorgrav wrote:
> 
> > Brian Somers <[EMAIL PROTECTED]> writes:
> > > Indeed.  I've been doing a ``make build'' on an OpenBSD-current vm 
> > > for three days (probably about 36 hours excluding suspends) on a 
> > > 366MHz laptop with a ATA33 disk.
> > 
> > Would it be possible for someone experiencing this slowdown to try to
> > narrow down the day (or even the week) on which it occurred?
> 
> I've experienced a substantial slowdown in VMware since bumping forwards
> from -STABLE on my workstation.  As I recently commented on -emulation,
> I've also been experiencing 30-40 second hangs of the system during VMware
> startup and occasional serious slowdown while running, which may be
> related to the fairly intensive VM activity for page wiring and the like,
> or possible poor interaction with the ATA driver.  I also get messages on
> the order of the following: 

The slowdown during start up appears to be in biowr; this is probably
because of IDE write caching being switched off.  More seriously
the vmware hangs during various phases of it's boot process.

i.e:

  714 root -14   0   123M 79192K inode0:45 25.29% 25.29% vmware

When this happens the whole machine freezes also.  Processes run, but
new processes don't get forked.  The whole machine appears to be I/O
bound.   (What's the 'inode' state?)

The problem is definitely solved by enabling ATA_ENABLE_WC in the kernel
config.  What's unclear to me is why the hang in 'inode' with it
switched off.  I understand that biowr's would take longer, which is
vmware does as it brings up the virtual machine, but why the hanging
and freezing in 'inode'?

Joe


RCS file: /home/ncvs/src/sys/dev/ata/ata-disk.c,v
retrieving revision 1.91
retrieving revision 1.92
diff -u -r1.91 -r1.92
--- ata-disk.c  2001/01/19 13:53:54 1.91
+++ ata-disk.c  2001/01/29 18:00:35 1.92
@@ -25,7 +25,7 @@
  * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
  * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
  *
- * $FreeBSD: src/sys/dev/ata/ata-disk.c,v 1.91 2001/01/19 13:53:54 peter Exp $
+ * $FreeBSD: src/sys/dev/ata/ata-disk.c,v 1.92 2001/01/29 18:00:35 sos Exp $
  */
 
 #include "opt_global.h"
@@ -133,10 +133,15 @@
0, 0, 0, 0, ATA_C_F_ENAB_RCACHE, ATA_WAIT_INTR))
printf("ad%d: enabling readahead cache failed\n", adp->lun);
 
+#if defined(ATA_ENABLE_WC) || defined(ATA_ENABLE_TAGS)
 if (ata_command(adp->controller, adp->unit, ATA_C_SETFEATURES,
0, 0, 0, 0, ATA_C_F_ENAB_WCACHE, ATA_WAIT_INTR))
printf("ad%d: enabling write cache failed\n", adp->lun);
-
+#else
+if (ata_command(adp->controller, adp->unit, ATA_C_SETFEATURES,
+   0, 0, 0, 0, ATA_C_F_DIS_WCACHE, ATA_WAIT_INTR))
+   printf("ad%d: disabling write cache failed\n", adp->lun);
+#endif
 /* use DMA if drive & controller supports it */
 ata_dmainit(adp->controller, adp->unit,
ata_pmode(AD_PARAM), ata_wmode(AD_PARAM), ata_umode(AD_PARAM));


 PGP signature

Re: vinum and qmail (RE: qmail IO problems)

[Dan Phoenix]

Yes I did and it made some real differences. I enabled it on /usr as well
as /var and mounted /var with the noatime option. Doing not bad for the
amount of email it is pushingthing is this I/O problem never use to be
an issuebut with growth constantly happening it has come to a hardware
based solution. What I have recommended to the company is a scsi card in
that machine with 2 scsi drives.I will raid 0 then together with ccd
or venim and mount it as /varturn existing /var into extra swap
space.although i may thing of something else...as I don;t think it
needs a gig of swap... and that should fix the I/O issue incredibly.
Right now I have split up the load also between2 machines so that has
helped out incrediblybut systat -vmstat is still always showing 100%
disk usage so I will have to remedy the problem. Then I plan on moving all
mail back to that one machine and beating the shit right out of that
freebsd machine to see what freebsd can really handle. If anyone has some
nice newbie docs :) on ccd or venim would be greatly appreciated.



On Thu, 8 Feb 2001, Julian Elischer wrote:

> Date: Thu, 08 Feb 2001 01:12:33 -0800
> From: Julian Elischer <[EMAIL PROTECTED]>
> To: Dan Phoenix <[EMAIL PROTECTED]>
> Cc: Matt Dillon <[EMAIL PROTECTED]>,
>  Andrew Reilly <[EMAIL PROTECTED]>,
>  Alfred Perlstein <[EMAIL PROTECTED]>,
>  Andre Oppermann <[EMAIL PROTECTED]>,
>  Rik van Riel <[EMAIL PROTECTED]>, Mike Silbersack <[EMAIL PROTECTED]>,
>  Poul-Henning Kamp <[EMAIL PROTECTED]>,
>  Charles Randall <[EMAIL PROTECTED]>, Jos Backus <[EMAIL PROTECTED]>,
>  [EMAIL PROTECTED]
> Subject: Re: vinum and qmail (RE: qmail IO problems)
> 
> Dan Phoenix wrote:
> > 
> > Yes maxusers stopped the dmesg errorsit seemed. Only thing I do not
> > like to much about postfix is that it only tries one MX record and then
> > does not try any others"default"yes there is still backlog with
> > #'s I gave you. Right now 8 min to get an email from sending...I have
> > another machine here still with qmail on itgoing to try to evenly
> > distribute the mail between them and see how it goes. I cannot get you
> > stats from linux box because i wiped it out with freebsdI will do
> > everything in my power to keep this box freebsd. Why qmail and linux was
> > handling the load I will never know now but regardless.with 600 megs
> > being pushed a day with all that included backlog .how many megs do
> > you think one ide drive can handle will be the biggest question to tackle
> > over next few days.
> >
> 
> 
> So, after that last discussion here, did you turn on soft updates?
> 
> -- 
>   __--_|\  Julian Elischer
>  /   \ [EMAIL PROTECTED]
> (   OZ) World tour 2000-2001
> ---> X_.---._/  
> v
> 



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: What's changed recently with vmware/linuxemu/file I/O

[Julian Elischer]

Josef Karthauser wrote:
> 
> The slowdown during start up appears to be in biowr; this is probably
> because of IDE write caching being switched off.  More seriously
> the vmware hangs during various phases of it's boot process.

Write caching is incompaible with soft updates.
The drive must NEVER report that something is on disk when it really is not!

> 
> i.e:
> 
>   714 root -14   0   123M 79192K inode0:45 25.29% 25.29% vmware
> 
> When this happens the whole machine freezes also.  Processes run, but
> new processes don't get forked.  The whole machine appears to be I/O
> bound.   (What's the 'inode' state?)
this sounds like a differnt starvation problem.
when it's happenning, what does 'iostat 1' show?
(how many transactions per second?)

I believe that vmware mmaps a region of memory and then somehow syncs 
it to disk. (It is certainly doing something like it here).


> 
> The problem is definitely solved by enabling ATA_ENABLE_WC in the kernel
> config.  What's unclear to me is why the hang in 'inode' with it
> switched off.  I understand that biowr's would take longer, which is
> vmware does as it brings up the virtual machine, but why the hanging
> and freezing in 'inode'?

maybe syncing mmapped regions locks out other types of activity?
Matt?


>
> +#else
> +if (ata_command(adp->controller, adp->unit, ATA_C_SETFEATURES,
> +   0, 0, 0, 0, ATA_C_F_DIS_WCACHE, ATA_WAIT_INTR))
> +   printf("ad%d: disabling write cache failed\n", adp->lun);
> +#endif
> 

we used to do this on the interjet because we ran soft updates.

-- 
  __--_|\  Julian Elischer
 /   \ [EMAIL PROTECTED]
(   OZ) World tour 2000-2001
---> X_.---._/  
v


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: vinum and qmail (RE: qmail IO problems)

[Geoff Buckingham]

On Thu, Feb 08, 2001 at 03:41:59AM -0800, Dan Phoenix wrote:
> 
> 
> 
> Yes I did and it made some real differences. I enabled it on /usr as well
> as /var and mounted /var with the noatime option. Doing not bad for the
> amount of email it is pushingthing is this I/O problem never use to be
> an issuebut with growth constantly happening it has come to a hardware
> based solution. What I have recommended to the company is a scsi card in
> that machine with 2 scsi drives.I will raid 0 then together with ccd
> or venim and mount it as /varturn existing /var into extra swap
> space.although i may thing of something else...as I don;t think it
> needs a gig of swap... and that should fix the I/O issue incredibly.
> Right now I have split up the load also between2 machines so that has
> helped out incrediblybut systat -vmstat is still always showing 100%
> disk usage so I will have to remedy the problem. Then I plan on moving all
> mail back to that one machine and beating the shit right out of that
> freebsd machine to see what freebsd can really handle. If anyone has some
> nice newbie docs :) on ccd or venim would be greatly appreciated.
> 
> 
A word of warning on this, when striping on an even number of drives 
using a power of 2 as as the stripe size, it is very easy to concentrate
meta data on one drive, thereby doing away with much of your performance gain.

Workarounds include striping at cluster size (16 or 32MB usually) using and
odd number of disks (for non raid 3/5), though or experimentation.

There should be a number of mails on the subject in the archives of the
scsi mailing list, look for myself or greg lehay to find the thread.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: vinum and qmail (RE: qmail IO problems)

[Julian Elischer]

Dan Phoenix wrote:
> 
> Yes I did and it made some real differences. I enabled it on /usr as well
> as /var and mounted /var with the noatime option. Doing not bad for the
> amount of email it is pushingthing is this I/O problem never use to be
> an issuebut with growth constantly happening it has come to a hardware
> based solution. What I have recommended to the company is a scsi card in
> that machine with 2 scsi drives.I will raid 0 then together with ccd
> or venim and mount it as /varturn existing /var into extra swap
> space.although i may thing of something else...as I don;t think it
> needs a gig of swap... and that should fix the I/O issue incredibly.
> Right now I have split up the load also between2 machines so that has
> helped out incrediblybut systat -vmstat is still always showing 100%
> disk usage so I will have to remedy the problem. Then I plan on moving all
> mail back to that one machine and beating the shit right out of that
> freebsd machine to see what freebsd can really handle. If anyone has some
> nice newbie docs :) on ccd or venim would be greatly appreciated.

Don't forget to put logging and other such things on a separate drive..
even a small 1G drive as a secondary will be ok, as long as it has soft 
updates and doesn't share heads with the work area..

vmstat 1 and iostat 1 output would be intersting.



-- 
  __--_|\  Julian Elischer
 /   \ [EMAIL PROTECTED]
(   OZ) World tour 2000-2001
---> X_.---._/  
v


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: What's changed recently with vmware/linuxemu/file I/O

[Josef Karthauser]

On Thu, Feb 08, 2001 at 04:08:12AM -0800, Julian Elischer wrote:
> Josef Karthauser wrote:
> > 
> >   714 root -14   0   123M 79192K inode0:45 25.29% 25.29% vmware
> > 
> > When this happens the whole machine freezes also.  Processes run, but
> > new processes don't get forked.  The whole machine appears to be I/O
> > bound.   (What's the 'inode' state?)
> this sounds like a differnt starvation problem.
> when it's happenning, what does 'iostat 1' show?
> (how many transactions per second?)

It looks like below.
Joe

  tty ad0  fd0 cpu
 tin tout  KB/t tps  MB/s   KB/t tps  MB/s  us ni sy in id
   0  179  8.00  67  0.53   0.00   0  0.00   0  0  0  2 98
   0   59  8.00  68  0.53   0.00   0  0.00   0  0  0  2 98
   0   60  8.00  68  0.53   0.00   0  0.00   0  0  0  2 98
   0   60  8.00  67  0.53   0.00   0  0.00   2  0  0  2 97
   0   59  8.00  66  0.52   0.00   0  0.00   1  0  2  2 95
   0   60  8.00  68  0.53   0.00   0  0.00   1  0  1  2 97
   0   60  8.00  68  0.53   0.00   0  0.00   0  0  1  2 98
   0   60  8.00  67  0.53   0.00   0  0.00   0  0  1  1 98
   0   59  8.00  66  0.52   0.00   0  0.00   0  0  0  2 98
  79   60  8.00  67  0.53   0.00   0  0.00   0  0  1  2 98
 183   60  8.00  68  0.53   0.00   0  0.00   0  0  3  2 95
 143   60  8.00  67  0.53   0.00   0  0.00   0  0  3  3 94
 197   59  8.00  67  0.53   0.00   0  0.00   1  0  1  2 97
  48   60  8.00  68  0.53   0.00   0  0.00   0  0  0  2 98
   8   60  8.00  67  0.53   0.00   0  0.00   0  0  2  2 96
 228   59  8.00  66  0.52   0.00   0  0.00   1  0  2  2 96
  40   60  8.00  67  0.53   0.00   0  0.00   0  0  2  2 96
   0   60  8.00  68  0.53   0.00   0  0.00   1  0  1  2 97
   0   60  8.00  67  0.53   0.00   0  0.00   1  0  1  3 95
   0   59  8.00  67  0.53   0.00   0  0.00   1  0  1  2 97
  tty ad0  fd0 cpu
 tin tout  KB/t tps  MB/s   KB/t tps  MB/s  us ni sy in id
   0  179  8.00  68  0.53   0.00   0  0.00   0  0  2  2 97
   0   60  8.00  67  0.53   0.00   0  0.00   1  0  1  2 96
   0   59  8.00  67  0.53   0.00   0  0.00   0  0  0  3 97
   0   60  8.00  67  0.53   0.00   0  0.00   0  0  0  2 98
   0   60  8.00  68  0.53   0.00   0  0.00   1  0  0  2 98
   0   60  8.00  67  0.53   0.00   0  0.00   0  0  0  2 98
   0   59  8.00  68  0.53   0.00   0  0.00   1  0  0  2 98
   0   60  8.00  67  0.53   0.00   0  0.00   0  0  0  2 98
   0   60  8.00  68  0.53   0.00   0  0.00   0  0  1  2 98
   0   59  8.00  67  0.53   0.00   0  0.00   0  0  2  2 95
   0   60  8.00  68  0.53   0.00   0  0.00   0  0  1  3 96
   0   60  8.00  68  0.53   0.00   0  0.00   2  0  1  2 95
   0   60  8.00  67  0.53   0.00   0  0.00   0  0  0  2 98
   0   59  8.00  68  0.53   0.00   0  0.00   0  0  0  2 98
   0   60  8.00  67  0.53   0.00   0  0.00   0  0  0  2 98
   0   60  8.00  68  0.53   0.00   0  0.00   0  0  0  2 98
   0   59  8.00  66  0.52   0.00   0  0.00   0  0  0  2 98
   0   60  8.00  66  0.52   0.00   0  0.00   0  0  0  2 98
   0   60  8.00  67  0.53   0.00   0  0.00   0  0  0  2 98
   0   60  8.00  68  0.53   0.00   0  0.00   0  0  0  2 98


 PGP signature

Re: vinum and qmail (RE: qmail IO problems)

[Dan Phoenix]

negative on that houston :)
http://www.FreeBSD.org/cgi/getmsg.cgi?fetch=52705+54899+/usr/local/www/db/text/2000/freebsd-scsi/20001008.freebsd-scsi
..i think maybe thread you are talking about.
Not to much info I could find on specifically on what you are talking
about. ...but again are you talking about venim or ccd?
I'll keep cluster solution in mind for the 2 disks.



On Thu, 8 Feb 2001, Geoff Buckingham wrote:

> Date: Thu, 8 Feb 2001 12:08:31 +
> From: Geoff Buckingham <[EMAIL PROTECTED]>
> To: Dan Phoenix <[EMAIL PROTECTED]>
> Cc: Julian Elischer <[EMAIL PROTECTED]>,
>  Matt Dillon <[EMAIL PROTECTED]>,
>  Andrew Reilly <[EMAIL PROTECTED]>,
>  Alfred Perlstein <[EMAIL PROTECTED]>,
>  Andre Oppermann <[EMAIL PROTECTED]>,
>  Rik van Riel <[EMAIL PROTECTED]>, Mike Silbersack <[EMAIL PROTECTED]>,
>  Poul-Henning Kamp <[EMAIL PROTECTED]>,
>  Charles Randall <[EMAIL PROTECTED]>, Jos Backus <[EMAIL PROTECTED]>,
>  [EMAIL PROTECTED]
> Subject: Re: vinum and qmail (RE: qmail IO problems)
> 
> On Thu, Feb 08, 2001 at 03:41:59AM -0800, Dan Phoenix wrote:
> > 
> > 
> > 
> > Yes I did and it made some real differences. I enabled it on /usr as well
> > as /var and mounted /var with the noatime option. Doing not bad for the
> > amount of email it is pushingthing is this I/O problem never use to be
> > an issuebut with growth constantly happening it has come to a hardware
> > based solution. What I have recommended to the company is a scsi card in
> > that machine with 2 scsi drives.I will raid 0 then together with ccd
> > or venim and mount it as /varturn existing /var into extra swap
> > space.although i may thing of something else...as I don;t think it
> > needs a gig of swap... and that should fix the I/O issue incredibly.
> > Right now I have split up the load also between2 machines so that has
> > helped out incrediblybut systat -vmstat is still always showing 100%
> > disk usage so I will have to remedy the problem. Then I plan on moving all
> > mail back to that one machine and beating the shit right out of that
> > freebsd machine to see what freebsd can really handle. If anyone has some
> > nice newbie docs :) on ccd or venim would be greatly appreciated.
> > 
> > 
> A word of warning on this, when striping on an even number of drives 
> using a power of 2 as as the stripe size, it is very easy to concentrate
> meta data on one drive, thereby doing away with much of your performance gain.
> 
> Workarounds include striping at cluster size (16 or 32MB usually) using and
> odd number of disks (for non raid 3/5), though or experimentation.
> 
> There should be a number of mails on the subject in the archives of the
> scsi mailing list, look for myself or greg lehay to find the thread.
> 



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: What's changed recently with vmware/linuxemu/file I/O

[Julian Elischer]

Josef Karthauser wrote:
> 
> On Thu, Feb 08, 2001 at 04:08:12AM -0800, Julian Elischer wrote:
> > Josef Karthauser wrote:
> > >
> > >   714 root -14   0   123M 79192K inode0:45 25.29% 25.29% vmware
> > >
> > > When this happens the whole machine freezes also.  Processes run, but
> > > new processes don't get forked.  The whole machine appears to be I/O
> > > bound.   (What's the 'inode' state?)
> > this sounds like a differnt starvation problem.
> > when it's happenning, what does 'iostat 1' show?
> > (how many transactions per second?)
> 
> It looks like below.

Looks like some way of clustering this might achieve a lot.

what does systat -vmstat or vmstat 1
show?
Better still, I guess we could do a linux-truss
and see what it's doing...


> Joe
> 
>   tty ad0  fd0 cpu
>  tin tout  KB/t tps  MB/s   KB/t tps  MB/s  us ni sy in id
>0  179  8.00  67  0.53   0.00   0  0.00   0  0  0  2 98
>0   59  8.00  68  0.53   0.00   0  0.00   0  0  0  2 98
>0   60  8.00  68  0.53   0.00   0  0.00   0  0  0  2 98
>0   60  8.00  67  0.53   0.00   0  0.00   2  0  0  2 97

-- 
  __--_|\  Julian Elischer
 /   \ [EMAIL PROTECTED]
(   OZ) World tour 2000-2001
---> X_.---._/  
v


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: vinum and qmail (RE: qmail IO problems)

[Anton Berezin]

On Wed, Feb 07, 2001 at 01:41:29PM -0800, Dan Phoenix wrote:

> Only thing I do not like to much about postfix is that it only tries
> one MX record and then does not try any others

Have a look at smtp_connect_timeout parameter (documented at
/usr/local/etc/postfix/sample-smtp.cf).

Cheers,
\Anton.
-- 
May the tuna salad be with you.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: What's changed recently with vmware/linuxemu/file I/O

[Dag-Erling Smorgrav]

Julian Elischer <[EMAIL PROTECTED]> writes:
> I believe that vmware mmaps a region of memory and then somehow syncs 
> it to disk. (It is certainly doing something like it here).

Theory: VMWare mmaps a region of memory corresponding to the virtual
machine's "physical" RAM, then touches every page during startup.
Unless some form of clustering is done, this causes 16384 write
operations for a 64 MB virtual machine...

DES
-- 
Dag-Erling Smorgrav - [EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: syscall kernel modules on 3.0-release

[Dag-Erling Smorgrav]

Matthew Emmerton <[EMAIL PROTECTED]> writes:
> That might work, but that requires boss/manager to have some idea of the
> technical implications of a) upgrading and b) remaining with old
> OS.  Depending on the organization, the situation may be
> next-to-impossible.  (And no saying I-told-you-so when it eventually
> breaks.)

Get a better job. Skilled IT workers are rare enough that they
shouldn't need to put up with such crap, and shouldn't have any
trouble getting a new job when the crap starts flying.

DES
-- 
Dag-Erling Smorgrav - [EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: What's changed recently with vmware/linuxemu/file I/O

[Josef Karthauser]

On Thu, Feb 08, 2001 at 04:58:17AM -0800, Julian Elischer wrote:
> 
> Looks like some way of clustering this might achieve a lot.
> 
> what does systat -vmstat or vmstat 1
> show?
> Better still, I guess we could do a linux-truss
> and see what it's doing...

I believe that it's strace under linux.  If someone can provide me
with a binary of this tool I'll happily run it here and see what
vmware's doing.

Joe

 PGP signature

Re: What's changed recently with vmware/linuxemu/file I/O

[David Malone]

On Thu, Feb 08, 2001 at 02:47:59PM +, Josef Karthauser wrote:
> > what does systat -vmstat or vmstat 1
> > show?
> > Better still, I guess we could do a linux-truss
> > and see what it's doing...
> 
> I believe that it's strace under linux.  If someone can provide me
> with a binary of this tool I'll happily run it here and see what
> vmware's doing.

You could use FreeBSD ktrace and then the linux_kdump port.

David.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

multiple IP addresses in /etc/hosts

[Eric Fiterman]

Hi:

  Is it possible to have an application like ping or telnet iterate
through IP addresses for a given hostname, if a previous attempt fails?

  For example:

  in /etc/hosts:
---
  0.0.0.1 testhost
  0.0.0.2 testhost
  0.0.0.3 testhost
---

If I attempt to 'ping testhost', and the first entry (0.0.0.1) fails, is
there anything to configure which would allow an automatic attempt to
ping 0.0.0.2? Is this possible?

Thanks

Eric



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: multiple IP addresses in /etc/hosts

[Nick Rogness]

On Thu, 8 Feb 2001, Eric Fiterman wrote:

> Hi:
> 
>   Is it possible to have an application like ping or telnet iterate
> through IP addresses for a given hostname, if a previous attempt fails?
> 
>   For example:
> 
>   in /etc/hosts:
> ---
>   0.0.0.1 testhost
>   0.0.0.2 testhost
>   0.0.0.3 testhost
> ---
> 
> If I attempt to 'ping testhost', and the first entry (0.0.0.1) fails, is
> there anything to configure which would allow an automatic attempt to
> ping 0.0.0.2? Is this possible?

AFAIK, not with /etc/hosts.  You could do round-robin DNS with
named but it will never be 100% of what you want to do. DNS does
not keep track of which hosts are dead or alive.

Nick Rogness <[EMAIL PROTECTED]>
- Keep on routing in a Free World...  
  "FreeBSD: The Power to Serve!"



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: multiple IP addresses in /etc/hosts

[Peter Pentchev]

On Thu, Feb 08, 2001 at 11:41:59AM -0500, Eric Fiterman wrote:
> Hi:
> 
>   Is it possible to have an application like ping or telnet iterate
> through IP addresses for a given hostname, if a previous attempt fails?
> 
>   For example:
> 
>   in /etc/hosts:
> ---
>   0.0.0.1 testhost
>   0.0.0.2 testhost
>   0.0.0.3 testhost
> ---
> 
> If I attempt to 'ping testhost', and the first entry (0.0.0.1) fails, is
> there anything to configure which would allow an automatic attempt to
> ping 0.0.0.2? Is this possible?

I do not think that any of the applications in the base system have
this ability.  The only place I've seen it (and am using it in several
home-grown apps) is in DJB's ucspi-tcp package (sysutils/ucspi-tcp, or
http://cr.yp.to/ucspi-tcp.html), in the 'tcpclient' utility.

If you specify a destination hostname that resolves to several IP
addresses, tcpclient shall try each one of them in turn until one is
successful.  You can specify the timeout and the retry count.

I guess one could write a telnet client that runs under tcpclient,
or adapt the one in the base system to read from fd 6 and write to
fd 7 (or the other way round, I forget).  Come to think of it,
adapting the base system telnet client to read/write to fd's specified
as cmdline options might be a nice idea.. I just might look into it.

G'luck,
Peter

-- 
This sentence no verb.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: multiple IP addresses in /etc/hosts

[Hajimu UMEMOTO]

> On Thu, 8 Feb 2001 18:51:50 +0200
> Peter Pentchev <[EMAIL PROTECTED]> said:

roam> I do not think that any of the applications in the base system have
roam> this ability.  The only place I've seen it (and am using it in several
roam> home-grown apps) is in DJB's ucspi-tcp package (sysutils/ucspi-tcp, or
roam> http://cr.yp.to/ucspi-tcp.html), in the 'tcpclient' utility.

IPv6 aware applications in base system such as telnet, ssh... do
round-robbin so that it can be fall back to use IPv4 if IPv6
connection is fail.

--
Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
[EMAIL PROTECTED]  [EMAIL PROTECTED]  ume@{,jp.}FreeBSD.org
http://www.imasy.org/~ume/


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: building boot floppies set

[Gustavo Vieira Goncalves Coelho Rios]

Nick Rogness wrote:
> 
> On Wed, 7 Feb 2001, Gustavo Vieira Goncalves Coelho Rios wrote:
> 
> > May some one give me some help where i can find documentation on
> > building my own boot floppy disk for freebsd ?
> 
> Most info about the FreeBSD OS can be obtained via the website
> at:
> 
> http://www.freebsd.org
> 
> For your particular question, the doc can be found at:
> 
> http://www.freebsd.org/handbook/install-guide.html#INSTALL-FLOPPIES
> 
> For future reference, questions like these should be sent to:
> 
> [EMAIL PROTECTED]
> 
> Best of Luck!
> 
> Nick Rogness
> - Keep on routing in a Free World...
>   "FreeBSD: The Power to Serve "


Hi gentleman, Thanks for your help, but i guess you did not get what i
meant!

I need to include support for a scsi controller that is not builtin the
boot.flp, so i have to build a boot.flp that includes the driver. That's
it! I am not refereing about installing the boot set onto diskettes!

Thanks a lot for your time and cooperation.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: vinum and qmail (RE: qmail IO problems)

[Matt Dillon]

:A word of warning on this, when striping on an even number of drives 
:using a power of 2 as as the stripe size, it is very easy to concentrate
:meta data on one drive, thereby doing away with much of your performance gain.
:
:Workarounds include striping at cluster size (16 or 32MB usually) using and
:odd number of disks (for non raid 3/5), though or experimentation.
:
:There should be a number of mails on the subject in the archives of the
:scsi mailing list, look for myself or greg lehay to find the thread.

I usually use a stripe size of 1152 for precisely that reason.  It's
relatively easy to test whether the metadata is being distributed
between the two drives reasonably, just look at the drive lights while
you are newfs'ing.

-Matt



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: vinum and qmail (RE: qmail IO problems)

[Matt Dillon]

:
:Don't forget to put logging and other such things on a separate drive..
:even a small 1G drive as a secondary will be ok, as long as it has soft 
:updates and doesn't share heads with the work area..
:
:vmstat 1 and iostat 1 output would be intersting.
:
:-- 
:  __--_|\  Julian Elischer

That's probably a little overkill.  Since the log files are not 
being fsync()'d, they won't generally interfere with other operations.

The real killer here is the fsync()ing that the mail system is doing
on every file, but that's the price you pay for reliable crash recovery.

-Matt



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: multiple IP addresses in /etc/hosts

[Peter Pentchev]

On Fri, Feb 09, 2001 at 02:06:31AM +0900, Hajimu UMEMOTO wrote:
> > On Thu, 8 Feb 2001 18:51:50 +0200
> 
> IPv6 aware applications in base system such as telnet, ssh... do
> round-robbin so that it can be fall back to use IPv4 if IPv6
> connection is fail.

Errr.. oops.  I must have been on something.

Of course base system telnet does round-robin.  Just noticed it
yesterday, when I tried telnet'ting to port 25 of a multi-addressed
MX by name, and it tried all addresses in turn.

So half the original question is answered :)

I do not really think such behavior belongs in 'ping' though,
especially seeing as ping is usually used as a diagnostics tool.
If a host does not respond, this might be temporary, or due to
timeouts, or due to some routing/interface problem.. most of the
time, I do want to see how it does as time goes by :)

G'luck,
Peter

-- 
This would easier understand fewer had omitted.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: soft updates and qmail (RE: qmail IO problems)

[Matt Dillon]

:>> already existing?
:>
:>Why not just read the man page for rename(2) before making
:>suggestions?
:
:I did. I'm glad I was right that it's deleting the destination that is
:the problem. I would have thought it would be easy to be sure that
:spool filenames are unique, but OTOH I guess that's not completely
:robust.
:
:Tony.
:-- 
:f.a.n.finch[EMAIL PROTECTED][EMAIL PROTECTED]

Yes, rename() will 'delete' the destination file if it previously
existed.  Of course, if the spool file names are unique then you
are not in danger of deleting anything on the destination.

If softupdates is turned on, rename() is 100% safe -- softupdates will
guarentee that the file will exist in one directory or the other, and
never get lost.  The absolute worst crash-case that can occur is for
the file to wind up in both directories (as if a hardlink had been
issued).  There is no need for a link() operation followed by a remove().

-Matt



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Kernel editing tools.

[Kevin Brunelle]

I just want to say thanks for all your help. I really like cscope and it
was almost exactly what I was looking for. I got several other great
ideas from some people. I like using a web browser for code browsing
when I just want to poke around and kill time. Just so you all know, vi
has an overwhelming majority of support on this list -- which is a great
thing because it is my favorite editor. And, several open terminal
windows seem to be the most popular way to go about kernel hacking;
which, is almost exactly what I was doing before. cscope really helps to
get things organized and find weird symbols.

Well, thanks again -- and happy hacking.

-Kevin Brunelle
-- 
Use the Source Luke!


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

RE: multiple IP addresses in /etc/hosts

[DINKEY,GENE (HP-Loveland,ex1)]

> -Original Message-
> From: Eric Fiterman [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, February 08, 2001 9:42 AM
> To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: multiple IP addresses in /etc/hosts
> 
> 
> Hi:
> 
>   Is it possible to have an application like ping or telnet iterate
> through IP addresses for a given hostname, if a previous 
> attempt fails?
> 
>   For example:
> 
>   in /etc/hosts:
> ---
>   0.0.0.1 testhost
>   0.0.0.2 testhost
>   0.0.0.3 testhost
> ---
> 
> If I attempt to 'ping testhost', and the first entry 
> (0.0.0.1) fails, is
> there anything to configure which would allow an automatic attempt to
> ping 0.0.0.2? Is this possible?


Not exactly sure what your trying to accomplish - just tryuing to verify
that the ip addresses are operating the way they should?

nmap will probably do what you need, it's a network scanner designed to do
things like scan whole subnets.  You will find it in ports/security/nmap
IIRC, not only is it a great network scanner but it will do other tricks
like jump through flaming hoops and TCP thumbprint remote OS's.

Gene Dinkey
aka
Master of my domain
aka
[EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: vinum and (now) postfix

[Thomas Strömberg]

Dan Phoenix wrote:
> 
> Yes maxusers stopped the dmesg errorsit seemed. Only thing I do not
> like to much about postfix is that it only tries one MX record and then
> does not try any others..

(slightly off topic)

In my experience, postfix is very nice about trying multiple MX records.
It should try every MX record twice. I normally wouldn't have posted,
but yesterday I remember seeing how many connections it tried to do
every time it delivered mail through fedex:

tstromberg@calamari (~)% host -t mx fedex.com
fedex.com mail is handled (pri=100) by mapper.mail.fedex.com
fedex.com mail is handled (pri=200) by smtp.zmd.fedex.com
fedex.com mail is handled (pri=300) by smtp.dmz.fedex.com

tstromberg@calamari (~)% gzcat /var/log/maillog.0.gz|grep 76000
Feb  7 17:19:25 calamari postfix/smtp[76000]: connect to
mapper.mail.fedex.com[199.81.10.25]: Connection refused (port 25)
Feb  7 17:19:25 calamari postfix/smtp[76000]: connect to
mapper.mail.fedex.com[199.81.10.26]: Connection refused (port 25)
Feb  7 17:19:25 calamari postfix/smtp[76000]: connect to
smtp.zmd.fedex.com[199.81.77.40]: Connection refused (port 25)
Feb  7 17:19:25 calamari postfix/smtp[76000]: connect to
smtp.zmd.fedex.com[199.81.77.41]: Connection refused (port 25)
Feb  7 17:19:25 calamari postfix/smtp[76000]: connect to
smtp.zmd.fedex.com[199.82.159.10]: Connection refused (port 25)
Feb  7 17:19:25 calamari postfix/smtp[76000]: connect to
smtp.zmd.fedex.com[199.82.159.11]: Connection refused (port 25)
Feb  7 17:19:26 calamari postfix/smtp[76000]: 55E3C1C9B1:
to=<[EMAIL PROTECTED]>, relay=smtp.dmz.fedex.com[199.81.194.38], delay=1,
status=sent (250 QAA09558 Message accepted for delivery)

This is with the postfix 20010204 snapshot. I can't guarantee any other
versions. 

-- 
---
name> thomas r. strombergwork> [EMAIL PROTECTED]
pos>  senior systems administrator   home> [EMAIL PROTECTED]
corp> research triangle commerce (icc.net)   web>  http://chaotical.ly/
---
earth has a lot of things other folks might want, like the whole planet
  -- william s. burroughs


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: vinum and (now) postfix

[Chris Faulhaber]

On Thu, Feb 08, 2001 at 03:00:23PM -0500, Thomas Strömberg wrote:
> Dan Phoenix wrote:
> > 
> > Yes maxusers stopped the dmesg errorsit seemed. Only thing I do not
> > like to much about postfix is that it only tries one MX record and then
> > does not try any others..
> 
> (slightly off topic)
> 
> In my experience, postfix is very nice about trying multiple MX records.
> It should try every MX record twice. I normally wouldn't have posted,
> but yesterday I remember seeing how many connections it tried to do
> every time it delivered mail through fedex:
> 

He may be referring to this FAQ entry:

http://www.postfix.org/faq.html#skip_greeting

-- 
Chris D. Faulhaber - [EMAIL PROTECTED] - [EMAIL PROTECTED]

FreeBSD: The Power To Serve   -   http://www.FreeBSD.org


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

FreeBSD Ports Security Advisory: FreeBSD-SA-01:INSERT_NUMBER_HERE

[FreeBSD Security Advisories]

=
FreeBSD-SA-01:INSERT_NUMBER_HERESecurity Advisory
FreeBSD, Inc.

Topic:  FreeBSD on record to set most advisory releases for
year 2001

Category:   All
Announced:  2001-02-07
Credits:[EMAIL PROTECTED] http://www.antioffline.com
Vendor status:  Developers sleeping right now
FreeBSD only:   Yes

I.   Background

FreeBSD is the most robust chopperating sysdumb in the world and we
mean it. Our TCP stack will kick your TCP stacks hynee. Currently we
are releasing an advisory every 1.95 days which means we are bound
to surpass Microsoft.

II.  Problem Description

We normally do not assess security when creating the ports distribution
often allowing anyone to build any program we decide to run in the ports
directory. Recently we have noticed that we can no longer fool users
into thinking because we provide checksumming for the programs, that
they will be secure.

Unlinke other operating systems and the developers of them who audit
their ports, we feel it is not our problem if someone accessess your
system because we're too lazy to do things right the first time.


III. Impact

Obviously anyone can end up control your machine or worse.

IV.  Workaround

We will not be mentioning the ultra secure OpenBSD operating system
since we feel it is not our problem and does not help to promote a
better OS than our own.

V.   Solution

One of the following:

1) Rub a magic lamp and wait for the security genie to fix it.

2) Download NSA Linux so you too can have miniscule backdoors in it
   which you won't see.

3) Pray to the hacker god Kevin Mitnick for assistance.

4) Install a more secure O(penBSD)S

NOTE: FreeBSD developers are now red faced

VI. Shouts

Hard Lee Strange
Mike Hunt
Ivana Swallows
Mike Hock
Dick Famous
Kathie Lee Gifford



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

new /etc/malloc.conf option

[Archie Cobbs]

Here's an idea for a new /etc/malloc.conf option to help with
debugging... I'm interested in what other people think.

The option would have the effect of setting a "failure probability"
P between 0.0 and 1.0 such that any malloc()/realloc() operation would
fail with probability P.

Sometimes I've implemented this kind of thing manually to test code
robustness and it's been very helpful in catching obscure bugs.

You can't do this with a single letter, but maybe we could do something
like this using a number between 0..100:

$ ln -s F5AJ /etc/malloc.conf

Then in the malloc code read out the 'F5' at startup and set
failure_prob to 5%...

static u_int failure_prob;  /* a number between 0 and 100 */

void *
malloc(size_t len)
{
u_int failure_index;

if (failure_prob != 0 && (random() % 100) < failure_prob) {
errno = ENOMEM;
return (NULL)
}
}

This would then give you a 1% failure probability.

By using random(), the exact failure can be reproduced by the application
by setting the same seed with srandom(). We might want to use a more
precise range, e.g., 0..100 instead of 0..100.

-Archie

__
Archie Cobbs * Packet Design * http://www.packetdesign.com


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

patch for if_sis to support SiS630E, need testers

[Bill Paul]

http://www.freebsd.org/~wpaul/SiS/sis.diff

This patch adds support for reading the station address from the
ATC CMOS RAM for board with the SiS 630E chipset with integrated
SiS 900 ethernet. I've verified that the patch compiles and doesn't
make the system explode, and it should have no effect on standalone
SiS 900 devices, however I don't currently have access to a host
with this chipset in it so I'm not 100% positive it does the right
thing. Those who have such hardware running 4.2-RELEASE, 4.2-STABLE
or -current, please apply the patch and let me know if the MAC
address is read correctly.

Note that the changes are hidden under #ifdef __i386__. The hacks
to make this work are specific to the x86 architecture, and the
SiS 630E chipset is only for x86 motherboards anyway. PCI adapters
based on the SiS 900 should still work on the alpha.

-Bill


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: new /etc/malloc.conf option

[Poul-Henning Kamp]

In message <[EMAIL PROTECTED]>, Archie Cobbs writes:
>Here's an idea for a new /etc/malloc.conf option to help with
>debugging... I'm interested in what other people think.
>
>The option would have the effect of setting a "failure probability"
>P between 0.0 and 1.0 such that any malloc()/realloc() operation would
>fail with probability P.

It's a good idea, but it needs improvement.  If malloc() fails with
a finite probability you will never get to test the end-game for most
processes.

Ideally you would give malloc a flag to say 'L'ook for failure, and
some covert channel would be dug through which you can control the
probability in batch or realtime mode.

Either way, I'm not sure it belongs in phkmalloc()

--
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

call for testers: port aggregation netgraph module

[Bill Paul]

http://www.freebsd.org/~wpaul/FEC/4.x/fec.tar.gz
http://www.freebsd.org/~wpaul/FEC/5.x/fec.tar.gz

This is a call for testers for a netgraph module that can be used to
aggregate 2 or 4 ethernet interfaces into a single interface. Basically,
it lets you do things like the following:

# kldload ./ng_fec.ko
# ngctl mkpeer fec dummy fec
# ngctl msg fec0: add_iface '"dc0"'
# ngctl msg fec0: add_iface '"dc1"'
# ngctl msg fec0: add_iface '"dc2"'
# ngctl msg fec0: add_iface '"dc3"'
# ngctl msg fec0: set_mode_inet

The fec module will work with *any* combination of interfaces, not
just multiport ethernet cards, however the port failover mechanism
will not work unless the interface supports ifmedia and is able to
report the link status. Cards that use the fxp, de, xl, tl, rl, sis,
dc, wb, ste, sf, vr, ti and sk drivers should work. Yes, that means
you can aggregate RealTek cards and gigabit ethernet cards together.

The channel bonding is done using the Cisco fast etherchannel mechanism.
The default hashing mechanism uses the MAC address, however you can
select IP address hashing as well. IPv4 and IPv6 address *should* work,
though I must admit I've been using IPv4 until now. If someone actually
has a Cisco switch that implements fast ethetchannel, I'd be interested
to know if it works with this module. At the moment, my test environment
consist of two machines with multiport ethernet cards wired up using
four crossover cables.

Each link is checked once every second to see if the link is still up.
An attempt to send a packet over a dead link will cause the packet to
be shifted over to the next link in the bundle.

There are tarballs for 4.x and 5.x systems. The 4.x tarball should
work on 4.2-RELEASE or later. The 5.x one will work on -current. Both
source and pre-compiled modules for x86 are provided. This code should
work on the alpha as well.

You can create more than one bundle by using more than one mkpeer
command with ngctl(8). You can delete interfaces from a bundle using
the del_iface command, which works just like the add_iface command.
The fec0 pseudo-interface will inherit the MAC address of the first
real interface to be added to the bundle, and that same MAC address
will be propagated to all subsequent interfaces that are added. The
MAC addresses are restored when an interface is removed from a bundle.
Once the bundle is created, you can manipulate the fec0 interface
as though it were a real ethernet interface. You must have either 2
or 4 NICs in the bundle.

Share, enjoy, test, and report back to me any problems you encounter.

-Bill


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: What's changed recently with vmware/linuxemu/file I/O

[Brian Somers]

> On Thu, Feb 08, 2001 at 04:58:17AM -0800, Julian Elischer wrote:
> >=20
> > Looks like some way of clustering this might achieve a lot.
> >=20
> > what does systat -vmstat or vmstat 1
> > show?
> > Better still, I guess we could do a linux-truss
> > and see what it's doing...
> 
> I believe that it's strace under linux.  If someone can provide me
> with a binary of this tool I'll happily run it here and see what
> vmware's doing.
> 
> Joe

The problem seems to have gone away after this (kindly pointed out to 
me by Maxim after my other post about xsane dropping cores):

: Subject: cvs commit: src/lib/libc/stdio findfp.c
: Date: Wed, 7 Feb 2001 09:34:50 -0800 (PST)
: From: Maxim Sobolev <[EMAIL PROTECTED]>
: To: [EMAIL PROTECTED], [EMAIL PROTECTED]
: 
: sobomax 2001/02/07 09:34:49 PST
: 
:   Modified files:
: lib/libc/stdio   findfp.c 
:   Log:
:   Fix a f^Hdamn typo, which prevented to fopen() more that 17 files at once.
:   
:   Tested by:  knu, sobomax and other #bsdcode'rs
:   
:   Revision  ChangesPath
:   1.9   +2 -2  src/lib/libc/stdio/findfp.c

-- 
Brian <[EMAIL PROTECTED]>
     
Don't _EVER_ lose your sense of humour !




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

mount_null and jail

[Attila Nagy]

Hello,

I am trying to do the following setup:

/jail
/jail-run

The first is a directory in a filesystem and holds the necessary files to
run the given application. The second directory is also a simple directory
but /jail mounted into it with mount_null.

The command I use to mount the first dir into the second is:
mount_null -o ro /jail/something /jail-run/something

The purpose of this setup is to create jails within a standard UFS
filesystem and to mount the directories read-only and run jailed
applications in it, on a read-only partition.
This wayI don't need several partitions, mounted RO and I don't have to
create loopback filesystems or to do other magic (like a mounted ISO).

The problem.

When I start jail I often get page faults.
Also I want to chroot() in the jail (ftp daemon) but it page faults in all
cases.

So
outside# jail /jail-run/something something 127.0.0.1 /bin/sh
often works and the jail starts (/jail-run is a NULL filesystem), but

inside# chroot
drops me a page fault and restarts the machine in every cases.

I've tried out this on 4.2-RELEASE and 4.2-STABLE (05/02/2001) -RELEASE
with a GENERIC and -STABLE with a custom kernel and all of them fail to
survive jail and chroot on a NULL FS.

Could somebody give me hints on this? I think it's a general problem and
the problem is the use of the NULL FS, but how could I avoid this kind of
crashes?

ps: I am subscribed only to freebsd-stable so if you write to -hackers
please CC me the message...

Thanks in advance,
--
Attila Nagye-mail:  [EMAIL PROTECTED]
Budapest Polytechnic (BMF.HU)   @work: +361 210 1415 (194)
H-1084 Budapest, Tavaszmezo u. 15-17.   cell.: +3630 306 6758



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: mount_null and jail

[Kris Kennaway]

On Thu, Feb 08, 2001 at 08:15:42PM +0100, Attila Nagy wrote:

> When I start jail I often get page faults.
> Also I want to chroot() in the jail (ftp daemon) but it page faults in all
> cases.

nullfs is broken in all versions prior to 5.0-CURRENT. This is even
documented in the manpage. I don't know if there are any plans to
backport the fixes, I understand they were fairly extensive.
 
Kris

 PGP signature

Cyclades Z under FreeBSD 4.2

[Greg Wohletz]

What is the status of the Cyclades Z driver under 4.2.  The cyclades site
only has drivers for 3.2, NetBSD has a driver for NetBSD 1.5.  I can't
find any reference to a driver for freebsd 4.2.  If you know of any
please tell me.

Greg


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

RE: known pthread bug?

[Charles Randall]

Does this update ERRATA.TXT on the FTP site too?

ftp://ftp.freebsd.org/pub/FreeBSD/releases/i386/4.2-RELEASE/ERRATA.TXT

-Charles

-Original Message-
From: Jordan Hubbard [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, February 06, 2001 11:03 PM
To: Charles Randall
Cc: 'Alfred Perlstein'; Paul D. Schmidt; [EMAIL PROTECTED]
Subject: Re: known pthread bug? 


> Why isn't ERRATA updated to reflect this? Should there be a "Known and
> acknowledged bugs" section in ERRATA?

The entire ERRATA is essentially a section like you describe, it just
doesn't always get updated. :-(

If any of the CVS committers see an errata-worthy item go by in the
repository, they're free to edit
www/en/releases/${release}/errata.sgml any time by the way.  It's
something I've certainly always tried to do when I had the time,
but I don't always have the time right now.

- Jordan


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Cyclades Z under FreeBSD 4.2

[Brooks Davis]

On Thu, Feb 08, 2001 at 02:07:32PM -0800, Greg Wohletz wrote:
> What is the status of the Cyclades Z driver under 4.2.  The cyclades site
> only has drivers for 3.2, NetBSD has a driver for NetBSD 1.5.  I can't
> find any reference to a driver for freebsd 4.2.  If you know of any
> please tell me.

You can get one for 4.2 at:

ftp://ftp.beta.com/pub/cyclades/cz210.tgz

-- Brooks

-- 
Any statement of the form "X is the one, true Y" is FALSE.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: multiple IP addresses in /etc/hosts

[Cliff Sarginson]

On Thu, Feb 08, 2001 at 11:09:01AM -0600, Nick Rogness wrote:
> On Thu, 8 Feb 2001, Eric Fiterman wrote:
> 
> > Hi:
> > 
> >   Is it possible to have an application like ping or telnet iterate
> > through IP addresses for a given hostname, if a previous attempt fails?
> > 
> >   For example:
> > 
> >   in /etc/hosts:
> > ---
> >   0.0.0.1 testhost
> >   0.0.0.2 testhost
> >   0.0.0.3 testhost
> > ---
> > 
> > If I attempt to 'ping testhost', and the first entry (0.0.0.1) fails, is
> > there anything to configure which would allow an automatic attempt to
> > ping 0.0.0.2? Is this possible?
> 
>   AFAIK, not with /etc/hosts.  You could do round-robin DNS with
>   named but it will never be 100% of what you want to do. DNS does
>   not keep track of which hosts are dead or alive.

Well, as far as ping goes you could do this in a very simple
way with a script that parses the hosts file and presents each
IP as an argument..or am I missing something here ?

Cliff


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

/etc/security: add md5 to suid change notification?

[Nick Sayer]

Would it generally be viewed as helpful to add the option of reporting
the md5 for the files listed in /var/log/setuid.*?

It would make the lines in that file very long, but in many cases they
already break the 80 character boundary anyhow.



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: mount_null and jail

[Aleksandr A.Babaylov]

Attila Nagy writes:
> Hello,
> 
> I am trying to do the following setup:
> 
> /jail
> /jail-run
> 
> The first is a directory in a filesystem and holds the necessary files to
> run the given application. The second directory is also a simple directory
> but /jail mounted into it with mount_null.
> 
> The command I use to mount the first dir into the second is:
> mount_null -o ro /jail/something /jail-run/something
> 
> The purpose of this setup is to create jails within a standard UFS
> filesystem and to mount the directories read-only and run jailed
> applications in it, on a read-only partition.
> This wayI don't need several partitions, mounted RO and I don't have to
> create loopback filesystems or to do other magic (like a mounted ISO).
> 
> The problem.
> 
> When I start jail I often get page faults.
> Also I want to chroot() in the jail (ftp daemon) but it page faults in all
> cases.
> 
> So
> outside# jail /jail-run/something something 127.0.0.1 /bin/sh
> often works and the jail starts (/jail-run is a NULL filesystem), but
> 
> inside# chroot
> drops me a page fault and restarts the machine in every cases.
> 
> I've tried out this on 4.2-RELEASE and 4.2-STABLE (05/02/2001) -RELEASE
> with a GENERIC and -STABLE with a custom kernel and all of them fail to
> survive jail and chroot on a NULL FS.
> 
> Could somebody give me hints on this? I think it's a general problem and
> the problem is the use of the NULL FS, but how could I avoid this kind of
> crashes?
Yes, you can use nullfs very restrictive.
I use such a method instead:
0garkin~(5)>df
Filesystem 1K-blocks UsedAvail Capacity  Mounted on
/dev/ad0s2h  7993324   440694  6913165 6%/usr
...
/dev/ad0s3a  7993324   439767  6914092 6%/jail/pent/usr
/usr and /jail/pent/usr is the same file system:
0garkin~(7)>fdisk ad0
*** Working on device /dev/ad0 ***
parameters extracted from in-core disklabel are:
cylinders=89355 heads=16 sectors/track=63 (1008 blks/cyl)
...
The data for partition 2 is:
sysid 165,(FreeBSD/NetBSD/386BSD)
start 25041744, size 65028096 (31752 Meg), flag 0
beg: cyl 267/ sector 1/ head 0;
end: cyl 266/ sector 63/ head 15
The data for partition 3 is:
sysid 0,(unused)
start 73812816, size 16257024 (7938 Meg), flag 0
beg: cyl 523/ sector 1/ head 0;
end: cyl 266/ sector 63/ head 15
ad0s3 is inside ad0s2 and:
0garkin~(8)>disklabel ad0s2
...
#size   offsetfstype   [fsize bsize bps/cpg]
  c: 650280960unused0 0 # (Cyl.0 - 4047*)
  d: 1625702404.2BSD0 0 0   # (Cyl.0 - 1011*)
  e:  8128512 162570244.2BSD0 0 0   # (Cyl. 1011*- 1517*)
  f:  8128512 243855364.2BSD0 0 0   # (Cyl. 1517*- 2023*)
  g: 16257024 325140484.2BSD0 0 0   # (Cyl. 2023*- 3035*)
  h: 16257024 487710724.2BSD0 0 0   # (Cyl. 3035*- 4047*)
ad0s3 ocupies the same place as ad0s2h.
More of that:
0garkin~(9)>fdisk ad0s3
*** Working on device /dev/ad0s3 ***
parameters extracted from in-core disklabel are:
cylinders=16128 heads=16 sectors/track=63 (1008 blks/cyl)

Figures below won't work with BIOS for partitions not in cyl 1
parameters to be used for BIOS calculations are:
cylinders=16128 heads=16 sectors/track=63 (1008 blks/cyl)

Media sector size is 512
Warning: BIOS sector numbering starts with sector 1
Information from DOS bootblock is:
The data for partition 1 is:
sysid 165,(FreeBSD/NetBSD/386BSD)
start 0, size 16257024 (7938 Meg), flag 80 (active)
beg: cyl 0/ sector 1/ head 0;
end: cyl 767/ sector 63/ head 15
The data for partition 2 is:
sysid 165,(FreeBSD/NetBSD/386BSD)
start 0, size 16257024 (7938 Meg), flag 0
beg: cyl 0/ sector 1/ head 0;
end: cyl 767/ sector 63/ head 15
The data for partition 3 is:
sysid 165,(FreeBSD/NetBSD/386BSD)
start 0, size 16257024 (7938 Meg), flag 0
beg: cyl 0/ sector 1/ head 0;
end: cyl 767/ sector 63/ head 15
The data for partition 4 is:
sysid 5,(Extended DOS)
start 0, size 16257024 (7938 Meg), flag 0
beg: cyl 0/ sector 1/ head 0;
end: cyl 767/ sector 63/ head 15
0garkin~(10)>disklabel ad0s3
...
#size   offsetfstype   [fsize bsize bps/cpg]
  a: 1625702404.2BSD 1024  819263   # (Cyl.0 - 16127)
  b: 1625702404.2BSD 1024  819263   # (Cyl.0 - 16127)
  c: 1625702404.2BSD 1024  819263   # (Cyl.0 - 16127)
  d: 1625702404.2BSD 1024  819263   # (Cyl.0 - 16127)
  e: 1625702404.2BSD 1024  819263   # (Cyl.0 - 16127)
  f: 1625702404.2BSD 1024  819263   # (Cyl.0 - 16127)
  g: 1625702404.2BSD 1024  819263   # (Cyl.0 - 16127)
  h: 1625702404.2BSD 1024  819263   # (Cyl.0 - 16127)
so your can use any of ad0s3[a-h] for read only mount in differ

unsubscribe

[Marcel Sauder]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: /etc/security: add md5 to suid change notification?

[Greg Black]

Nick Sayer wrote:

> Would it generally be viewed as helpful to add the option of reporting
> the md5 for the files listed in /var/log/setuid.*?

I don't see the benefit in this if either the md5 binary or the
comparison file are on writable storage (which is almost always
going to be true).


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: /etc/security: add md5 to suid change notification?

[Kris Kennaway]

On Thu, Feb 08, 2001 at 03:55:41PM -0800, Nick Sayer wrote:
> Would it generally be viewed as helpful to add the option of reporting
> the md5 for the files listed in /var/log/setuid.*?

To what end? We already know the files changed - adding their MD5
doesn't seem to provide the administrator with any additional
information.

Kris
 PGP signature

Re: call for testers: port aggregation netgraph module

[Chris Dillon]

On Thu, 8 Feb 2001, Bill Paul wrote:

> http://www.freebsd.org/~wpaul/FEC/4.x/fec.tar.gz
> http://www.freebsd.org/~wpaul/FEC/5.x/fec.tar.gz
>
> This is a call for testers for a netgraph module that can be used
> to aggregate 2 or 4 ethernet interfaces into a single interface.
> Basically, it lets you do things like the following:

[snip]

> The fec module will work with *any* combination of interfaces, not
> just multiport ethernet cards, however the port failover mechanism
> will not work unless the interface supports ifmedia and is able to
> report the link status. Cards that use the fxp, de, xl, tl, rl,
> sis, dc, wb, ste, sf, vr, ti and sk drivers should work. Yes, that
> means you can aggregate RealTek cards and gigabit ethernet cards
> together.

Awesome!  I've been using channel bonding/port-failover on my NT
servers for at least a couple of years now.  One thing, though,
wouldn't the plural of 'fec' be 'feces'?  :-)

> The channel bonding is done using the Cisco fast etherchannel
> mechanism. The default hashing mechanism uses the MAC address,
> however you can select IP address hashing as well. IPv4 and IPv6
> address *should* work, though I must admit I've been using IPv4
> until now. If someone actually has a Cisco switch that implements
> fast ethetchannel, I'd be interested to know if it works with this
> module. At the moment, my test environment consist of two machines
> with multiport ethernet cards wired up using four crossover
> cables.

Apparently there is another way to do channel bonding with switches
that don't support Cisco's EtherChannel, since I'm doing it with
3COM's (piece of *hit) SuperStackII switches and I don't have
EtherChannel support enabled in Compaq's NT drivers for their Intel
NICs.

I will try this out on -stable at work, but the only switches I have
handy that support EtherChannel are some HP ProCurve 4000Ms.  Is there
any chance that the EtherChannel method would work on something like a
3COM SuperStackII 3300, which doesn't claim to support EtherChannel?

> Each link is checked once every second to see if the link is still
> up. An attempt to send a packet over a dead link will cause the
> packet to be shifted over to the next link in the bundle.

Apparently Compaq's NT driver (actually most likely Intel's, slightly
modified by Compaq) sends out a heartbeat packet from each interface
if there has been no incoming traffic on the interfaces within the
heartbeat period.  I haven't sniffed the heartbeat packet yet to
figure out if it is simply sent to a broadcast address (which it
appears to be, since the switch appears to forward it to all ports),
or if it is sending it from one interface addressed to another
interface, or even to the same interface.

[snip]

> The fec0 pseudo-interface will inherit the MAC address of the first
> real interface to be added to the bundle, and that same MAC address
> will be propagated to all subsequent interfaces that are added.

[snip]

Hmmm... The non-EtherChannel method apparently uses a different MAC
for each interface, since when I have looked at the forwarding tables
of my switches where I have two bonded channels from a server, each
port shows a different MAC address.  Any idea how that would work?
It would be really cool if you could choose either the EtherChannel
method or some other non-EtherChannel method that will work with other
switches, if we can figure out how it works.  :-)


-- Chris Dillon - [EMAIL PROTECTED] - [EMAIL PROTECTED]
   FreeBSD: The fastest and most stable server OS on the planet.
   For IA32 and Alpha architectures. IA64, PPC, and ARM under development.
   http://www.freebsd.org




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: new /etc/malloc.conf option

[Matt Dillon]

:Here's an idea for a new /etc/malloc.conf option to help with
:debugging... I'm interested in what other people think.
:
:The option would have the effect of setting a "failure probability"
:P between 0.0 and 1.0 such that any malloc()/realloc() operation would
:fail with probability P.
:...
:
:By using random(), the exact failure can be reproduced by the application
:
:-Archie
:__
:Archie Cobbs * Packet Design * http://www.packetdesign.com

A system-wide global?  Ouch.  How about not.

I can't imagine using this on random software.  I can see it for
big projects, but in that case why not simply write a wrapper
for malloc() for that project?

I usually wrap malloc() with a function called zalloc() (which also
zero's the returned memory), and free() with a function called
zfree() which takes an extra size argument.  The debug version of
these functions track and verify all allocations and frees based on
the source file, line, and function they were called from (cpp magic) and
dumps a histogram every 10K allocations or so (which makes finding
memory leaks trivial).

The default version also core dumps the programs if the underlying
malloc() fails.  I have safe_*() versions of all the string/malloc
functions as well (e.g. safe_asprintf(), safe_strdup()) which also core
the program if the underlying malloc fails.

I've found that code becomes utterly unreadable if every single call that
might malloc something has to be checked for failure.  It's easier to
design the program such that a malloc failure should never occur (for
example, by limiting the number of simultanious connections a threaded
program is allowed to handle), and then core dump if one actually does
occur.

-Matt



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: What's changed recently with vmware/linuxemu/file I/O

[Andrew Gallatin]

Dag-Erling Smorgrav writes:
 > Julian Elischer <[EMAIL PROTECTED]> writes:
 > > I believe that vmware mmaps a region of memory and then somehow syncs 
 > > it to disk. (It is certainly doing something like it here).
 > 
 > Theory: VMWare mmaps a region of memory corresponding to the virtual
 > machine's "physical" RAM, then touches every page during startup.
 > Unless some form of clustering is done, this causes 16384 write
 > operations for a 64 MB virtual machine...
 > 

Pretty much.  But the issue is that this should never hit the disk
unless we're under memory pressure because it is mapped MAP_NOSYNC
(actually the file is unlinked prior to the mmap() and a heuristic in
vm_mmap() detects this and sets MAP_NOSYNC).

The real problem is that our MAP_NOSYNC doesn't fully work in at least
one major case.  As I understand it, the technique we use is to set
the MAP_ENTRY_NOSYNC in the map entry at mmap time. On a write fault,
PG_NOSYNC is set in the page's flags.  A lazy msync will skip
PG_NOSYNC pages.

The problem comes when a page is read from prior to being written
to.  The page gets mapped in read/write and we don't take a write
fault, so the PG_NOSYNC flag never gets set.  (This accounts for the
flurry of disk i/o shortly after vmware starts).  When the pages get
sunk to disk, the vnode is locked and the application will freeze in a
"vmpfw" 

The following patch sets PG_NOSYNC on faults other than write faults.
This seems to work for my test program, and for vmware (I've only very
briefly tested it).  Assuming that it is correct, the code around it
should be reorganized somewhat.   This is against -stable, as I don't
have any -current i386s..

Index: vm_fault.c
===
RCS file: /home/ncvs/src/sys/vm/vm_fault.c,v
retrieving revision 1.108.2.2
diff -u -r1.108.2.2 vm_fault.c
--- vm_fault.c  2000/08/04 22:31:11 1.108.2.2
+++ vm_fault.c  2001/02/08 23:04:02
@@ -804,6 +804,10 @@
}
vm_page_dirty(fs.m);
vm_pager_page_unswapped(fs.m);
+   } else {
+   if ((fs.entry->eflags & MAP_ENTRY_NOSYNC) && 
+   (fs.m->dirty == 0))
+   vm_page_flag_set(fs.m, PG_NOSYNC);
}
}
 


Cheers,

Drew

--
Andrew Gallatin, Sr Systems Programmer  http://www.cs.duke.edu/~gallatin
Duke University Email: [EMAIL PROTECTED]
Department of Computer Science  Phone: (919) 660-6590


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

mount checking for read-only media

[Kenny Drobnack]

There's this little problem with FreeBSD that has been bugging me a bit
for a while now.  There have been a couple times I've tried to mount Zip
disks or floppy drives in FreeBSD, and had the /etc/fstab set up to
mount read/write, and didn't realize that I had write protect turned
on.  However, I didn't realize the write protect was turned on until I
tried writing to the drive.  This caused lots of hard write errors or
some such thing, and the system eventual just said "hit any key to
reboot".  I guess some buffer somewhere got full and crashed the
kernel.  There's never any kernel dump, so I can't easily send debug
messages.  Is there some reason that no check is done to make sure the
media is writable before writing to it?
Is some system call to check the hardware to see if its physically
writable?  I figure there is.  I want to start hacking at the kernel a
bit, and it seems like something simple (comparitively) would be a good
place to start.  Up there on my wish list is getting a journaling
filesystem ported to FreeBSD.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: mount checking for read-only media

[Warner Losh]

In message <[EMAIL PROTECTED]> Kenny Drobnack writes:
:   Is some system call to check the hardware to see if its physically
: writable?  I figure there is.  I want to start hacking at the kernel a
: bit, and it seems like something simple (comparitively) would be a good
: place to start.  Up there on my wish list is getting a journaling
: filesystem ported to FreeBSD.

This is a driver bug.  The da driver, which deals with disks, doesn't
check to see if the media is writable or not before allowing r/w
mounts.  You could short circuit the panic by fixing this.

Fixing the panic might be harder...

Warner


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: soft updates and qmail (RE: qmail IO problems)

[Matt Dillon]

Well, after a long conversation with Mr Bernstein and Kirk it turns out
that all my blathering about a normal FFS mount being easily corruptable
due to a crash occuring during heavy disk I/O (e.g. from qmail) is so
much smoke.

The fsync()/rename() combination that QMail does should be sufficient to
guarentee (baring a bug in kernel) that a crash will not result in any
lost mail queue files when using a normal FFS mount (without softupdates).

However, I still recommend using softupdates.

-Matt




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

FFS Driver for win2000?

[janb]

Does anybody know of any attempt to write a Fast Filesystem driver for
windows 2000?. I have a machine that dual boots, and I can see the NTFS
under FreeBSD no problem, but I would like to see my freebsd volume under
windows, too.

Is this a good project for me to do, or has someone done this already?


JAn



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: FFS Driver for win2000?

[Kris Kennaway]

On Thu, Feb 08, 2001 at 11:13:42PM -0700, [EMAIL PROTECTED] wrote:
> Does anybody know of any attempt to write a Fast Filesystem driver for
> windows 2000?. I have a machine that dual boots, and I can see the NTFS
> under FreeBSD no problem, but I would like to see my freebsd volume under
> windows, too.
> 
> Is this a good project for me to do, or has someone done this already?

 :-)

It would be pretty useful, but obviously you'd have to know an awful
lot about the internals of Windows 2000.

Kris

 PGP signature

Re: mount checking for read-only media

[Matthew Emmerton]

> In message <[EMAIL PROTECTED]> Kenny Drobnack writes:
> : Up there on my wish list is getting a journaling
> : filesystem ported to FreeBSD.

You may wish to check out IBM's JFS port for Linux
(http://oss.software.ibm.com/developerworks/opensource/jfs/)  It's released
under the GPL.  The nice thing about it is that there's 25 point-in-time
releases, each enabling a new feature, which makes for easy testing.

--
Matt Emmerton





To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: mount checking for read-only media

[Kevin Brunelle]

Well,

> This is a driver bug.  The da driver, which deals with disks, doesn't
> check to see if the media is writable or not before allowing r/w
> mounts.  You could short circuit the panic by fixing this.

I know this is going to sound corny, but if this gets fixed I am going
to miss it.

#ifdef SAGA

After I had been using FreeBSD for a while I realized I had never seen a
kernel panic. So I specifically went and tried to cause one. It took
several days of looking through the code and I still found nothing. I
needed to go to school, but I knew I had a class where I could look at
some code if I brought it with me. I grabbed a disk, mounted it, and
started copying files to it. There was no problem for a while, but then
it tried to start writing the data; instant kernel panic. The disk was
write protected and I had accidentally found what I was looking for. I
did figure out where it must be, but I never looked for it; I never
really wanted to find it. I figured if I found it, I would want to fix
it. I assumed the occurrence must be rare, and if it wasn't, a better
programmer than myself would offer a fix to it. Instead I used it to
show my friends what a kernel panic looked like, and explain to them
exactly the lengths it took to get my system to mess up. This was
amazing to them, as they were Windows users and to them a crash was a
daily occurrence. I also used it to show how even programs that had been
in use for a long time, could still have bugs in them.

As the months flew by, as they seem to do with FreeBSD. I showed people
less and less, and I guess I really forgot about it. [I think I first
found it in 3.4-RELEASE] I guess I assumed it was fixed, although I
never checked. Now, I know it is still there, and I will miss it when it
is gone. This is one of my favorite bugs. If it does get fixed, I might
just keep a copy of the old source around -- for the memories.

#endif

[HHOS] Yes, I know I have problems. ;-)

Kevin Brunelle
-- 
"Do not meddle in the affairs of sysadmins,
for they are subtle and quick to anger."
HHOS=Ha ha only serious.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message