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

Matt Dillon wrote: > And, I would say, that for any mailer creating and deleting files in > a spool directory at a high rate, *ONLY* a filesystem with softupdates > turned on or a journaling filesystem such as XFS or ReiserFS can be > considered crash-surviveable. Synchronous met

Re: CVSup7.FreeBSD.org is back in service

John Polstra <[EMAIL PROTECTED]> wrote: > >The folks who run the mirrors in Japan have a very nice setup which >uses SNMP to query the number of active CVSup clients on each mirror. >They don't do automatic load balancing with it currently, but they >make some nice graphs available on the web for

Interesting Java problem

I'm fooling around with java and have installed the linux port of java 1.3 on a 4.2-STABLE system (last cvsuped and make world on Jan 30). I'm running a very simple java program ; public class HelloWorld { public static void main(String[] args) { System.out.println("Hello

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, t

RE: known pthread bug?

>From: Alfred Perlstein [mailto:[EMAIL PROTECTED]] > >1) 4.2 RELEASE has known pthreads bugs, you should upgrade to -stable. This is the second time I've seen this mentioned on -hackers. How is a poor, unsuspecting soul^Wdeveloper supposed to know this? Why isn't ERRATA updated to reflect this?

unsubscribe

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)

On Tue, Feb 06, 2001 at 12:13:57PM -0800, Alfred Perlstein wrote: > * Andre Oppermann <[EMAIL PROTECTED]> [010206 12:07] wrote: > > Does sendmail even use fsync()? > > It better. :) Quick grep of the sendmail sources shows most of the six fsync calls protected by a flag (SuperSafe && or nofsync

RE: What is the latest "known-good" PXE build ?

On 06-Feb-01 Matt Simerson wrote: > Anyway, that should help you out considerably. If I could legally give away > a floppy with WIN-98 MSDOS installed and the fboot.exe program I would but I > think doing so violates a software license or two. > Have you looked at Free-DOS ?

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

> Bruce Evans wrote: > > > > On Tue, 6 Feb 2001, Josef Karthauser wrote: > > > > > I'm wondering what's changed recently to cause vmware2 running on > > > the linuxemu to lose a lot of performance with disk I/O. > > > > Use of cmpxchg and possibly other SMP pessimizations. > > > > > A couple o

Re: Help with PXE boot, install and related...

Indispensible URL for this: http://people.freebsd.org/~alfred/pxe/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message

Re: 3 Stage Boot Issues

[EMAIL PROTECTED] wrote: > I would like to contribute! > > What's the formal process? There isn't one.. Start with the www.freebsd.org site and have a look at the documentation and handbook - there is a how-to-contribute section in there. Have a look at the 3-stage boot code (src/lib/libstand,

RE: What is the latest "known-good" PXE build ?

On Tue, 6 Feb 2001, Matt Simerson wrote: > Anyway, that should help you out considerably. If I could legally give away > a floppy with WIN-98 MSDOS installed and the fboot.exe program I would but I > think doing so violates a software license or two. > > Matt How about using caldera dr-dos (or

RE: What is the latest "known-good" PXE build ?

I have a "magic floppy" which is nothing more than a DOS boot floppy with the fboot.exe program on it and a BIOS image. This works like a charm for my netbooting purposes: Intel (R) Boot Agent Version 4.0.12 PXE 2.0 Build 082 (Wfm 2.0), RPC v2.7.3 Press Ctrl+S to enter the Setup Menu I've wr

Re: What is the latest "known-good" PXE build ?

Mike Smith ([EMAIL PROTECTED]) wrote: > > > > The BIOS trace says the PXE is revision 2.0, build 68 : is there some other, > > > > perhaps better version of it ? (the on-board NIC on the machine is an fxp) > > > > > > Build 068 is a disaster; you ideally want 082 or later. > > > > is there some

3 Stage Boot Issues

I would like to contribute! What's the formal process? email: [EMAIL PROTECTED] Ramil J.Santamaria Toshiba America Information Systems, Inc Computer Systems Division 50 Parker Irvine, CA 92618 Office: (949) 461-4379 Fax: (949) 837-9047 Fax: (949) 206-3439 Email: [EMAIL PROTECTED] To Unsubsc

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

Andre Oppermann wrote: > > > Since when does `atomic' equal `synchronous' ? > > Because otherwise it would not be atomically, would it? I am loath to add to this bloated thread, but... atomic and durable aren't the same thing. This is why A.C.I.D. semantics contain both A & D. The atomicit

Re: MRTG like graphs without SNMP: howto.

On Tue, Feb 06, 2001 at 09:16:38PM +0100, Poul-Henning Kamp wrote: > > I sat down and hacked a couple of shellscripts to give a basic > graphing of the interface trafic on a FreeBSD box without taking > the detour around SNMP. > > The result is available here: > > http://phk.free

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

Alfred Perlstein wrote: > > * Andre Oppermann <[EMAIL PROTECTED]> [010206 12:58] wrote: > > Alfred Perlstein wrote: > > > > > > Basically, you want a fsync right before the IPC. This should > > > bring the metadata up to date with what's in-core and you should > > > then be safe when you reply w

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

* Andre Oppermann <[EMAIL PROTECTED]> [010206 12:58] wrote: > Alfred Perlstein wrote: > > > > Basically, you want a fsync right before the IPC. This should > > bring the metadata up to date with what's in-core and you should > > then be safe when you reply with your 250 accepted message. > > Li

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

Alfred Perlstein wrote: > > > Does sendmail even use fsync()? > > It better. :) since the last time I know of, Kirk and Eric lived in the same building it would seem likely that Eric would know to do that.. > -- __--_|\ Julian Elischer / \ [EMAIL PROTECTED] ( OZ

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

Alfred Perlstein wrote: > > * Andre Oppermann <[EMAIL PROTECTED]> [010206 12:33] wrote: > > Alfred Perlstein wrote: > > > > > > * Andre Oppermann <[EMAIL PROTECTED]> [010206 12:07] wrote: > > > > > > > > Yes, my understanding of the meaning of "ordered meta-date update" as > > > > I have grasped

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

* Andre Oppermann <[EMAIL PROTECTED]> [010206 12:33] wrote: > Alfred Perlstein wrote: > > > > * Andre Oppermann <[EMAIL PROTECTED]> [010206 12:07] wrote: > > > > > > Yes, my understanding of the meaning of "ordered meta-date update" as > > > I have grasped it from Terry's rants in the past years

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

Alfred Perlstein wrote: > > * Andre Oppermann <[EMAIL PROTECTED]> [010206 12:30] wrote: > > Rik van Riel wrote: > > > > > > On Tue, 6 Feb 2001, Andre Oppermann wrote: > > > > > > > But please answer me one question: Is the link() call atomically > > > > in FFS/UFS w or w/o softupdates? Meaning wh

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

-On [20010206 20:25], Andre Oppermann ([EMAIL PROTECTED]) wrote: >> ... provided that qmail calls fsync(2). > >$ cd qmail-ldap/ >$ grep fsync * | wc -l > 21 Of course that says nothing if the fsync()'s are not placed at strategic places. fsync(); fsync(); fsync

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

* Andre Oppermann <[EMAIL PROTECTED]> [010206 12:30] wrote: > Rik van Riel wrote: > > > > On Tue, 6 Feb 2001, Andre Oppermann wrote: > > > > > But please answer me one question: Is the link() call atomically > > > in FFS/UFS w or w/o softupdates? Meaning when the call returns > > > the meta- dat

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

On Tue, 6 Feb 2001, Andre Oppermann wrote: > Rik van Riel wrote: > > On Tue, 6 Feb 2001, Andre Oppermann wrote: > > > > > But please answer me one question: Is the link() call atomically > > > in FFS/UFS w or w/o softupdates? Meaning when the call returns > > > the meta- data is written to stable

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

Alfred Perlstein wrote: > > * Andre Oppermann <[EMAIL PROTECTED]> [010206 12:07] wrote: > > > > Yes, my understanding of the meaning of "ordered meta-date update" as > > I have grasped it from Terry's rants in the past years is not that all > > meta-data updates on a filesystem have to be done on

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

* Matt Dillon <[EMAIL PROTECTED]> [010206 12:19] wrote: > :> banging on unrelated areas of the filesystem in parallel, and an > :> fsync() of one descriptor would have to wait for the entire filesystem > :> to reach a synchronization point to guarentee metadata update ordering. > :>

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

Rik van Riel wrote: > > On Tue, 6 Feb 2001, Andre Oppermann wrote: > > > But please answer me one question: Is the link() call atomically > > in FFS/UFS w or w/o softupdates? Meaning when the call returns > > the meta- data is written to stable storage like with fsync()? > > Since when does `at

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

On Tue, 6 Feb 2001, Andre Oppermann wrote: > But please answer me one question: Is the link() call atomically > in FFS/UFS w or w/o softupdates? Meaning when the call returns > the meta- data is written to stable storage like with fsync()? Since when does `atomic' equal `synchronous' ? regards,

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

Matt Dillon wrote: > > : > :This information is in fact correct. Have a look at the FreeBSD link(2) > :man page: > : > :LINK(2) FreeBSD System Calls Manual > :LINK(2) > > Andre, I think there *might* be a dozen people in the world that > understand UFS/FFS better then I

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

:> banging on unrelated areas of the filesystem in parallel, and an :> fsync() of one descriptor would have to wait for the entire filesystem :> to reach a synchronization point to guarentee metadata update ordering. :> This creates a serious scaleability issue within a filesystem!

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

* Andre Oppermann <[EMAIL PROTECTED]> [010206 12:07] wrote: > > Yes, my understanding of the meaning of "ordered meta-date update" as > I have grasped it from Terry's rants in the past years is not that all > meta-data updates on a filesystem have to be done one-after-the-other > but ordered in re

MRTG like graphs without SNMP: howto.

I sat down and hacked a couple of shellscripts to give a basic graphing of the interface trafic on a FreeBSD box without taking the detour around SNMP. The result is available here: http://phk.freebsd.dk/IfTraf/ Enjoy, -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [

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

Rik van Riel wrote: > > On Tue, 6 Feb 2001, Andre Oppermann wrote: > > Rik van Riel wrote: > > > On Tue, 6 Feb 2001, Matt Dillon wrote: > > > > > > Reiserfs and ext3 have write-ahead logs and, AFAIK, fsync() > > > will not return until there is a commit point in the log. > > > > Also FFS/UFS will

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

Matt Dillon wrote: > > :> Pre-softupdate BSD semantics, apparently. Doesn't sound like > :> the smartest thing to do when you want a reliable MTA... > : > :This description is not entirely right. > : > :Qmail depends on ordered-metadata updates (Terry! :-). That means > :if you issue a link() to

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

On Tue, Feb 06, 2001 at 10:59:09AM -0800, Matt Dillon wrote: > I did a quick search of the qmail site but couldn't find an email > address to report the FAQ issue to. Try sending mail to [EMAIL PROTECTED] -- Jos Backus _/ _/_/_/"Modularity is not a hack."

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

Since I'm still being cc'd on this... :) * Matt Dillon <[EMAIL PROTECTED]> [010206 11:56] wrote: > : > :This information is in fact correct. Have a look at the FreeBSD link(2) > :man page: > : > :LINK(2) FreeBSD System Calls Manual > :LINK(2) > > Andre, I t

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

: :This information is in fact correct. Have a look at the FreeBSD link(2) :man page: : :LINK(2) FreeBSD System Calls Manual :LINK(2) Andre, I think there *might* be a dozen people in the world that understand UFS/FFS better then I do, but none of them h

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

Rik van Riel wrote: > > On Tue, 6 Feb 2001, Andre Oppermann wrote: > > > Qmail depends on ordered-metadata updates (Terry! :-). That > > means if you issue a link() to the new place and a unlink() in > > the old place it should guarantee that the link() happens > > *BEFORE* the unlink(). > > >

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

Matt Dillon wrote: > > :On Tue, 6 Feb 2001, Matt Dillon wrote: > : > :> I did a quick search of the qmail site but couldn't find an email > :> address to report the FAQ issue to. If QMail calls fsync() in a > :> reasonable manner, then softupdates is perfectly safe and the QMail > :>

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

On Tue, 6 Feb 2001, Andre Oppermann wrote: > Rik van Riel wrote: > > On Tue, 6 Feb 2001, Matt Dillon wrote: > > > > Reiserfs and ext3 have write-ahead logs and, AFAIK, fsync() > > will not return until there is a commit point in the log. > > Also FFS/UFS will not return before the file and direc

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

:> Pre-softupdate BSD semantics, apparently. Doesn't sound like :> the smartest thing to do when you want a reliable MTA... : :This description is not entirely right. : :Qmail depends on ordered-metadata updates (Terry! :-). That means :if you issue a link() to the new place and a unlink() in the

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

Mike Silbersack wrote: > > On Tue, 6 Feb 2001, Matt Dillon wrote: > > > I did a quick search of the qmail site but couldn't find an email > > address to report the FAQ issue to. If QMail calls fsync() in a > > reasonable manner, then softupdates is perfectly safe and the QMail > >

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

On Tue, 6 Feb 2001, Andre Oppermann wrote: > Qmail depends on ordered-metadata updates (Terry! :-). That > means if you issue a link() to the new place and a unlink() in > the old place it should guarantee that the link() happens > *BEFORE* the unlink(). > > As it is, I can only recommend people

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

On Tue, 6 Feb 2001, Andre Oppermann wrote: > Date: Tue, 06 Feb 2001 20:32:07 +0100 > From: Andre Oppermann <[EMAIL PROTECTED]> > NAME > link - make a hard file link > DESCRIPTION > The link() function call atomically creates the specified directory > entry >

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

Rik van Riel wrote: > > On Tue, 6 Feb 2001, Matt Dillon wrote: > > > QMail's FAQ is totally incorrect. No major filesystem -- be it > > FFS, EX2FS, Reiser, FFS+Softupdates, guarentees that when you > > write() and close() a file that the file will then survive a disk > > crash.

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

Matt Dillon wrote: > > :Well, the various qmail programs do seem to fsync (though I'm not sure if > :it's in the right places.) In any case, this link seems to throw some > :light on the situation: > : > :ftp://elektroni.ee.tut.fi/pub/qmail_linux_metadata_message > : > :Now, I have no clue if th

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

Rik van Riel wrote: > > On Tue, 6 Feb 2001, Mike Silbersack wrote: > > On Tue, 6 Feb 2001, Rik van Riel wrote: > > > > > The system call used to guarantee this is fsync (and friends?); > > > if qmail doesn't use it but makes assumptions that aren't true > > > on any decent OS out there ... > > >

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

Matt Dillon wrote: > > :>softupdates disk may wind up unwinding 'more' of the last few moments > :>worth of operations then a normal filesystem would. And, I might add, > :>Reiser is the same way. > :> > :>The only way to guarentee that file data is written to disk, with any > :>

Re: echo request deny

On Tue, 6 Feb 2001, milunovic wrote: > Is there anyway to deny echo request on FreeBSD (except ipfw add deny > icmp from any to any) ? > On Linux It was simple,just echo 1>/proc/.../icmp_echo_request If you just want to block echo_requests and don't want to block any other ICMP w

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

Poul-Henning Kamp wrote: > > In message <[EMAIL PROTECTED]>, Matt Dillon writes: > > > >: > >:In message <[EMAIL PROTECTED]>, >Charles Randall writes: > >:>The qmail FAQ specifically recommends against soft updates for the mail > >:>queue. > >:> > >:>http://cr.yp.to/qmail/faq/reliability.html#fi

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

:On Tue, 6 Feb 2001, Matt Dillon wrote: : :> I did a quick search of the qmail site but couldn't find an email :> address to report the FAQ issue to. If QMail calls fsync() in a :> reasonable manner, then softupdates is perfectly safe and the QMail :> FAQ needs to be updated to r

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

Rik van Riel wrote: > > On Tue, 6 Feb 2001, Poul-Henning Kamp wrote: > > In message <[EMAIL PROTECTED]>, >Charles Randall writes: > > >The qmail FAQ specifically recommends against soft updates for the mail > > >queue. > > > > > >http://cr.yp.to/qmail/faq/reliability.html#filesystems > > > > > >

Re: Clustering FreeBSD

:PW> :PW>I have a 15K rpm drive if you want to do a recalculation. I think that :PW>is 1.05Mach, depending on whether you rounded or not. ;-) : :Well, 7cm gives 21cm per rotation or 2.1km for 1 rotations. 1 :Rotations Per Minute give around 130km per hour which is somewhere around :0.1MA

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

On Tue, 6 Feb 2001, Matt Dillon wrote: > I did a quick search of the qmail site but couldn't find an email > address to report the FAQ issue to. If QMail calls fsync() in a > reasonable manner, then softupdates is perfectly safe and the QMail > FAQ needs to be updated to recomme

Re: echo request deny

At 12:05 06/02/01 +, milunovic wrote: >Is there anyway to deny echo request on FreeBSD (except ipfw add deny >icmp from any to any) ? >On Linux It was simple,just echo 1>/proc/.../icmp_echo_request 'ifconfig ifacename down' does the same, and even more. just kidding:) I don't see a valid rea

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

:Poul-Henning Kamp wrote: :> :> In message <[EMAIL PROTECTED]>, :Charles Randall writes: :> >The qmail FAQ specifically recommends against soft updates for the mail :> >queue. :> > :> >http://cr.yp.to/qmail/faq/reliability.html#filesystems :> > :> >Is this incorrect? :> > :> :> It seems to indi

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

On Tue, 6 Feb 2001, Matt Dillon wrote: > :Reiserfs and ext3 have write-ahead logs and, AFAIK, fsync() > :will not return until there is a commit point in the log. > : > :This means that fsync() will guarantee that the transactions > :won't be unwound (unless I've overlooked some weird special > :

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

Poul-Henning Kamp wrote: > > In message <[EMAIL PROTECTED]>, >Charles Randall writes: > >The qmail FAQ specifically recommends against soft updates for the mail > >queue. > > > >http://cr.yp.to/qmail/faq/reliability.html#filesystems > > > >Is this incorrect? > > > > It seems to indicate that qm

Re: What is the latest "known-good" PXE build ?

> > > The BIOS trace says the PXE is revision 2.0, build 68 : is there some other, > > > perhaps better version of it ? (the on-board NIC on the machine is an fxp) > > > > Build 068 is a disaster; you ideally want 082 or later. > > is there some standard way to upgrade the pxe code on the cards

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

:> consistent state. Softupdates is considerably better at guarenteeing :> this consistency (as is something like Reiser), but if you crash a :> softupdates disk may wind up unwinding 'more' of the last few moments :> worth of operations then a normal filesystem would. And, I mig

Re: What is the latest "known-good" PXE build ?

> > The BIOS trace says the PXE is revision 2.0, build 68 : is there some other, > > perhaps better version of it ? (the on-board NIC on the machine is an fxp) > > Build 068 is a disaster; you ideally want 082 or later. is there some standard way to upgrade the pxe code on the cards ? in case, w

Re: What is the latest "known-good" PXE build ?

> I haven't tracked these changes, and am still using some slightly older > rc files. I've updated my rc.diskless stuff to use mdconfig now though; > if there's interest I'll put it up for review. yes please... i'd like to fix things as needed so that diskless scripts work correctly in our ne

Re: What is the latest "known-good" PXE build ?

> > The BIOS trace says the PXE is revision 2.0, build 68 : is there some other, > perhaps better version of it ? (the on-board NIC on the machine is an fxp) Build 068 is a disaster; you ideally want 082 or later. > PS : As I've seen, rc has been modified to get rid of > "early_nfs_mounts". Aft

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

:kirk said (but I have not completely checked it) that if you fsync a file, :it will effectively fsync all the way back to the root of the filesystem. : :I don't know how true this is, but cerainly the inode is updated before :fsync returns. I cannot tell if any directory entries pointing at tha

What is the latest "known-good" PXE build ?

Hello, I'm trying to use the pxeboot loader from 4.2-RELEASE, to diskless boot some rack-mount PCs. Using documentation from Alfred Perlstein and Mike Smith, I've configured a DHCP server and a tftp server, and I'm still having problems with at least one machine not being able to start each ti

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

Mike Silbersack wrote: > > On Tue, 6 Feb 2001, Rik van Riel wrote: > > > The system call used to guarantee this is fsync (and friends?); > > if qmail doesn't use it but makes assumptions that aren't true > > on any decent OS out there ... > > > > regards, > > > > Rik > > Well, the various qmail

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

In message <[EMAIL PROTECTED]>, Matt Dillon writes: >:>softupdates disk may wind up unwinding 'more' of the last few moments >:>worth of operations then a normal filesystem would. And, I might add, >:>Reiser is the same way. >:> >:>The only way to guarentee that file data is writt

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

:>with fsync(), so softupdates is not going to be too much worse then :>other FS's. : :Actually, if you don't use fsync you do loose more work with :softupdates than if you use plain UFS. : :Softupdates can delay directory updates which plain UFS will runs :synchronously, and consequentl

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

On Tue, 6 Feb 2001, Matt Dillon wrote: > QMail's FAQ is totally incorrect. No major filesystem -- be it > FFS, EX2FS, Reiser, FFS+Softupdates, guarentees that when you > write() and close() a file that the file will then survive a disk > crash. All these filesystems guarentee is

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

On Tue, 6 Feb 2001, Mike Silbersack wrote: > On Tue, 6 Feb 2001, Rik van Riel wrote: > > > The system call used to guarantee this is fsync (and friends?); > > if qmail doesn't use it but makes assumptions that aren't true > > on any decent OS out there ... > > Well, the various qmail programs do

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

:Well, the various qmail programs do seem to fsync (though I'm not sure if :it's in the right places.) In any case, this link seems to throw some :light on the situation: : :ftp://elektroni.ee.tut.fi/pub/qmail_linux_metadata_message : :Now, I have no clue if this is correct or not, but the core o

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

:>softupdates disk may wind up unwinding 'more' of the last few moments :>worth of operations then a normal filesystem would. And, I might add, :>Reiser is the same way. :> :>The only way to guarentee that file data is written to disk, with any :>filesystem no matter how it is

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

In message <[EMAIL PROTECTED]>, Matt Dillon writes: > >: >:In message <[EMAIL PROTECTED]>, >Charles Randall writes: >:>The qmail FAQ specifically recommends against soft updates for the mail >:>queue. >:> >:>http://cr.yp.to/qmail/faq/reliability.html#filesystems >:> >:>Is this incorrect? >:> >: >

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

On Tue, 6 Feb 2001, Rik van Riel wrote: > The system call used to guarantee this is fsync (and friends?); > if qmail doesn't use it but makes assumptions that aren't true > on any decent OS out there ... > > regards, > > Rik Well, the various qmail programs do seem to fsync (though I'm not sure

Re: qmail IO problems

: :On Mon, 5 Feb 2001, Matt Dillon wrote: : :> :file: table is full : :> :looutput: mbuf allocation failed :> :nfs server 172.16.0.101:/bravenet1/home: is alive again : :> This sheds a considerable amount of light on the problems... :> methinks you may have a low 'maxusers' setting in the

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

On Tue, 6 Feb 2001, Poul-Henning Kamp wrote: > In message <[EMAIL PROTECTED]>, >Charles Randall writes: > >The qmail FAQ specifically recommends against soft updates for the mail > >queue. > > > >http://cr.yp.to/qmail/faq/reliability.html#filesystems > > > >Is this incorrect? > > It seems to ind

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

: :In message <[EMAIL PROTECTED]>, :Charles Randall writes: :>The qmail FAQ specifically recommends against soft updates for the mail :>queue. :> :>http://cr.yp.to/qmail/faq/reliability.html#filesystems :> :>Is this incorrect? :> : :It seems to indicate that qmail doesn't use fsync(2) as much as

Re: echo request deny

On Tue, 6 Feb 2001, David Malone wrote: > On Tue, Feb 06, 2001 at 12:05:47PM +, milunovic wrote: > > Is there anyway to deny echo request on FreeBSD (except ipfw add deny > > icmp from any to any) ? > > On Linux It was simple,just echo 1>/proc/.../icmp_echo_request > > You can limit the icmp

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

In message <[EMAIL PROTECTED]>, Charles Randall writes: >The qmail FAQ specifically recommends against soft updates for the mail >queue. > >http://cr.yp.to/qmail/faq/reliability.html#filesystems > >Is this incorrect? > It seems to indicate that qmail doesn't use fsync(2) as much as it should do.

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

Bruce Evans wrote: > > On Tue, 6 Feb 2001, Josef Karthauser wrote: > > > I'm wondering what's changed recently to cause vmware2 running on > > the linuxemu to lose a lot of performance with disk I/O. > > Use of cmpxchg and possibly other SMP pessimizations. > > > A couple of weeks ago I could

soft updates and qmail (RE: qmail IO problems)

The qmail FAQ specifically recommends against soft updates for the mail queue. http://cr.yp.to/qmail/faq/reliability.html#filesystems Is this incorrect? This section also warns against async filesystems on Linux for the qmail queue. Charles -Original Message- From: Matt Dillon [mailto

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

On Wed, Feb 07, 2001 at 02:40:27AM +1100, Bruce Evans wrote: > > Could someone please hit me with a clue-bat :) > > Read your freebsd-emulation mail :-). /me wanders off to subscribe to freebsd-emulation. Thanks Bruce. Joe PGP signature

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

On Tue, 6 Feb 2001, Josef Karthauser wrote: > I'm wondering what's changed recently to cause vmware2 running on > the linuxemu to lose a lot of performance with disk I/O. Use of cmpxchg and possibly other SMP pessimizations. > A couple of weeks ago I could boot win2000 under vmware2 in a matter

`top' strange results and `pkg_add' bug on STABLE system

Hello All, I've build & install whole world from sources. Sources was cvsupped at 2 of February. I've install world on two computers: 1) iP250MMx/64Mb. 2) i486DX4-100/24Mb. System works perfectly on iP250 computer, but same system (installed over NFS from same /usr/obj and /usr/sr

Re: Extremely large (70TB) File system/server planning

>While talking to a friend about what his company is planning to do, >I found out that he is planning a 70TB filesystem/servers/cluster/db. >(Yes, seventy t-e-r-a-b-y-t-e...) We could do this using about 44 of the not-yet-announced TSR-3100 fibre channel RAID storage systems. These are 1.8TB (

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

Hi, I'm wondering what's changed recently to cause vmware2 running on the linuxemu to lose a lot of performance with disk I/O. A couple of weeks ago I could boot win2000 under vmware2 in a matter of minutes; on today's kernel it takes 5 or 10 minutes to boot, and disk I/O is through the roof.

Re: qmail IO problems

On Mon, 5 Feb 2001, Matt Dillon wrote: > :file: table is full > :looutput: mbuf allocation failed > :nfs server 172.16.0.101:/bravenet1/home: is alive again > This sheds a considerable amount of light on the problems... > methinks you may have a low 'maxusers' setting in the kernel >

Re: echo request deny

On Tue, Feb 06, 2001 at 12:05:47PM +, milunovic wrote: > Is there anyway to deny echo request on FreeBSD (except ipfw add deny > icmp from any to any) ? > On Linux It was simple,just echo 1>/proc/.../icmp_echo_request You can limit the icmp response rate with: sysctl -w net.inet.icmp

Re: How to use parallel port tape drive

On Fri, Feb 02, 2001 at 08:30:35PM -0500, James Halstead wrote: > I have a tape drive (hp coloradoo700) which uses qic-3010 tapes. I wanted to > use it but I do not know how to access the drive over the parallel port. The > only tape drives I saw in the NOTES file are scsi. > > Can somebody pleas

echo request deny

Is there anyway to deny echo request on FreeBSD (except ipfw add deny icmp from any to any) ? On Linux It was simple,just echo 1>/proc/.../icmp_echo_request To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message

VM Questions - Swap "Disabling"

I've been digging for this answer through various resources, including the source code and various search engines and can't find the answer to this. By the way, those of you who work in the vm code are either gods or have a mind which is significantly more twisted than mine. (That was a complim