Linux getcwd problems

[Koster, K.J.]

Dear All,

I just ran into a problem with the linuxulator, triggered by the Linux JDK
that I use for my development.

Markus kindly pointed me to this PR:
  http://www.freebsd.org/cgi/query-pr.cgi?pr=24315

The summary is that getcwd(3) under Linux emulation will fail really
hard after a rmdir.

Does anyone have time to sit down and fix this? You would be my hero (or
heroin, as the case may be).

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: technical comparison

[Daniel C. Sobral]

Shannon Hendrix wrote:
> 
> > And just to get things worse... :-) the test must be made on the *same*
> > slice. If you configure two different slices, the one on the outer
> > tracks will be faster.
> 
> I cannot verify that with my drive, but my largest is 18GB so maybe
> the difference is not as pronounced as on some newer drives like those
> (currently) monster 70GB drives.

It should be measurable.

On one hand, more sectors per track, same time to read a single track =
more bytes read per second.

On the other hand, more sectors per track, more bytes per track, less
tracks per same size, less track seek needed.

-- 
Daniel C. Sobral(8-DCS)
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]

wow regex humor... I'm a geek

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

Re: Linux getcwd problems

[Alfred Perlstein]

* Koster, K.J. <[EMAIL PROTECTED]> [010523 05:48] wrote:
> Dear All,
> 
> I just ran into a problem with the linuxulator, triggered by the Linux JDK
> that I use for my development.
> 
> Markus kindly pointed me to this PR:
>   http://www.freebsd.org/cgi/query-pr.cgi?pr=24315
> 
> The summary is that getcwd(3) under Linux emulation will fail really
> hard after a rmdir.
> 
> Does anyone have time to sit down and fix this? You would be my hero (or
> heroin, as the case may be).

I've looked at your email and the PR, the problem that I have is that
I have no clue as to what it should return.  Can you give a suggestion
and possibly site a refernece?  Basically, WWLD (what would linux do)?

-- 
-Alfred Perlstein [[EMAIL PROTECTED]]
Instead of asking why a piece of software is using "1970s technology,"
start asking why software is ignoring 30 years of accumulated wisdom.

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

Re: technical comparison

[Eric Melville]

> The proposed filesystem is most likely Reiserfs. This is a true
> journalling filesystem with a radically non-traditional layout.
> It is no problem to put millions of files in a single directory.
> (actually, the all-in-one approach performs better than a tree)
> 
> XFS and JFS are similarly capable, but Reiserfs is well tested
> and part of the official Linux kernel. You can get the Reiserfs
> team to support you too, in case you want to bypass the normal
> filesystem interface for even better performance.

It should be noted that simply because something is tested and a part of a
release, it is not automatically wonderful. My last experiance with linux
was in the 2.2 days, and ended with a lost root filesystem while attempting
to access an msdosfs drive.

>From what I've read, mixing reiserfs and nfs is about as exciting as the
stock market has been in the last few months.

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

RE: Linux getcwd problems

[Koster, K.J.]

Dear Alfred,

>
> >   http://www.freebsd.org/cgi/query-pr.cgi?pr=24315
> > 
> > The summary is that getcwd(3) under Linux emulation will fail really
> > hard after a rmdir.
> > 
> I've looked at your email and the PR, the problem that I have is that
> I have no clue as to what it should return.  Can you give a suggestion
> and possibly site a refernece?  Basically, WWLD (what would linux do)?
> 
Umm. I'm confused. WLWD is give me a useful value for cwd, given that my cwd
actually exists.

What I see is this:

% touch build.xml
% mkdir gen
% rmdir gen
% ant
Buildfile: build.xml
 
BUILD FAILED

java.io.FileNotFoundException: iÉ/build.xml (No such file or directory)
   ^^- note this

It looks like that after a directory was removed from the cwd, the Linux
getcwd command returns garbage. The JDK uses getcwd routinely, to set the
user.dir (or some such) property. Ant uses that property to determine what
file to open, i.e. it opens (in a mix of C, Java and pseudocode):

  new FileInputStream(linux_getcwd() + "/build.xml")

Since getcwd() returns garbage after a directory was deleted from the cwd,
the above fails with the exception mentioned earlier.

I think it is safe to assume that on a Linux system, getcwd() returns
meaningful information every time, under normal circumstances. :-)

This is about as clear as I can describe the problem. Hope this helps.

>
> Instead of asking why a piece of software is using "1970s technology,"
> start asking why software is ignoring 30 years of accumulated wisdom.
>
Because today I know better. [Ghandi] :-)

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: Linux getcwd problems

[David Malone]

On Wed, May 23, 2001 at 01:02:01PM +0100, Koster, K.J. wrote:

The problem seems to be that FreeBSD's getcwd library call will
impliment the getcwd userland if the syscall fails or is unimplimented.

There are times when the syscall fails in normal operation and you
don't see this with the BSD stuff 'cos it is covered up by the
userland implimentation. You can check this by kdumping a FreeBSD
version of your cwd program and searching for the return value of
the __getcwd syscall.

The Linux emulation stuff just calls the FreeBSD syscall, but I
guess the Linux libraries don't expect getcwd to fail, so they
can't do the userland magic.

I haven't had a chance to look at how hard it would be to fix the
FreeBSD getcwd call to always work, or to fake the Linux stuff so
that it somehow did the equivelent of the userland thing.

David.

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

Re: technical comparison

[Peter Pentchev]

On Wed, May 23, 2001 at 08:17:12AM -0400, Andresen,Jason R. wrote:
> On Tue, 22 May 2001, Kris Kennaway wrote:
> 
> > On Tue, May 22, 2001 at 10:27:27PM +0300, Nadav Eiron wrote:
> > > I ran tests that I think are similar to what Jason ran on identically
> > > configured FreeBSD and Linux/ReiserFS machines. ResierFS is much much
> > > faster than UFS+softupdates on these tests.
> > >
> > > Linux (2.2.14-5 + ReiserFS):
> > > Time:
> > > 164 seconds total
> > > 97 seconds of transactions (103 per second)
> > >
> > > Files:
> > > 65052 created (396 per second)
> > > Creation alone: 6 files (1090 per second)
> > > Mixed with transactions: 5052 files (52 per second)
> > > 4936 read (50 per second)
> > > 5063 appended (52 per second)
> > > 65052 deleted (396 per second)
> > > Deletion alone: 60104 files (5008 per second)
> > > Mixed with transactions: 4948 files (51 per second)
> > >
> > > Data:
> > > 24.83 megabytes read (155.01 kilobytes per second)
> > > 336.87 megabytes written (2.05 megabytes per second)
> > >
> > > FreeBSD 4.3-RELEASE (ufs/softupdates):
> >
> > Did you enable write caching?  You didn't mention, and it's off by
> > default in 4.3, but I think enabled by default on Linux.
> 
> I tried to leave the FreeBSD and Linux boxes as unchanged as possible for
> my tests (they are lab machines that have other uses, although I made sure
> they were idle during the test periods).
> 
> I left write caching enabled in the Linux boxes, and left it disabled on
> the FreeBSD boxes.  Personally, I'm hesitant to enable write caching
> on FreeBSD because we tend to use it on machines where we really really
> don't want to lose data.  Write caching is ok on the Linux machines
> because we use them as pure testbeds that we can reconstruct easily if
> their disks go south.

If the tests on the Linux machines are made to simulate how those Linux
machines would operate if used as production servers, then do that:
configure the Linux machines exactly as if they were your production
servers.  That is, if you want write caching off on production servers,
turn it off at test time.

G'luck,
Peter

-- 
If you think this sentence is confusing, then change one pig.

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

Re: technical comparison

[Andresen,Jason R.]

On Tue, 22 May 2001, Daniel C. Sobral wrote:

> Jason Andresen wrote:
> >
> > If only FreeBSD could boot from those funky M-Systems flash disks.
>
> It can.

How?  Nothing I found in the documentation indicated this, or gave any
sort hint as to how I might go about doing it.  The Linux driver has a
hacked version of Lilo that has to be installed prior to even thinking of
doing anything with the flash, but I found no equivelent for FreeBSDs
boot1.

FreeBSD can mount the disks just fine (I used a custom PicoBSD boot floppy
to fix up the Linux install on the flash disk enough so that it would boot
(the stupid script M-Systems provided installed a completely hosed
system!)).

This sort of information might be handy to have on freebsd.org.


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

Re: technical comparison

[Andresen,Jason R.]

On Tue, 22 May 2001, Daniel C. Sobral wrote:

> Jason Andresen wrote:
> >
> > Results:
> > ufs+softupdates is a little slower than ext2fs+wc for low numbers of
> > files, but scales better.  I wish I had a Reiserfs partition to
> > test with.
>
> Ext2fs is a non-contender.
>
> Note, though, that there is some very recent perfomance improvement on
> very large directories known as dirpref (what changed, actually, was
> dirpref's algorithm). This is NOT present on 4.3-RELEASE, though it
> _might_ have since been committed to stable.

The new dirpref code is mostly just a performance tweak.  We can't compete
with ReiserFS on large directories without a major improvement to the
code, assuming the previous post was true and ReiserFS has some log time
components where ufs has linear time components.

Note that the improvement from using the new dirpref code is about 12%,
which isn't bad, but still doesn't put us in the right ballpark.


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

RE: technical comparison

[Koster, K.J.]

Dear All,

An interview with Reiser just appeared on http://www.slashdot.org/

Just to add a little oil to the fire. :-)

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: technical comparison

[Andresen,Jason R.]

On Tue, 22 May 2001, Shannon Hendrix wrote:

> On Tue, May 22, 2001 at 09:31:34AM -0400, Jason Andresen wrote:
>
> > We only have three Linux boxes here (and one is a PC104 with a flash
> > disk) and already I've had to reinstall the entire OS once when we had a
> > power glitch.  ext2fsck managed to destroy about 1/3 of the files on the
> > system, in a pretty much random manner (the lib and etc were hit hard).
>
> This is not typical. Also, I have heard the same thing from other people
> about flash disks. fs crash, fsck, and a mess afterwards. It would be
> nice if you could use ufs and see if the same problem exists.

The scary thing is that it was the attached harddrive that lost all of the
files.  The situitation is this:

Attached HD: I just installed Redhat on the hard drive.  I rebooted and
the system booted off of the harddrive normally.  Successful install.  I
logged into the system and started looking into rebuilding the kernel to
include the binary only M-Systems modules when a co-worker accidentally
unplugged the wrong plug (he was working on some nearby machines),
unplugging the power supply I was using to power the hard drives (and
pretty much crashing the PC104 system).  I powered down the PC104 system,
and we plugged everything in again.  When I tried to reboot the system,
Lilo couldn't even find the kernel.  I pulled out the emergency resuce
disc (RedHat's install disk) and booted it up.  When I ran fsck on the
drive, it found error after error on the drive.  Eventually I had to ^C
that fsck run and try it again with the -y option (my arm was getting
tired).  Once fsck was done / was pretty much a ghost town, at which point
I decided to just reinstall the system.

It's entirely possible that there is something I could have done to
prevent fsck from clearing out the filesystem, but it certainly isn't
obvious from the manual, and I've never seen a FreeBSD system do that.

Also, for anybody who says the pull the power test isn't realistic, I can
assure you that power failures DO happen (probably less in your area than
mine (I hope!)) and not planning for them only brings disaster later when
you have a room with 1000 servers lose power.


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

Re: technical comparison

[Andresen,Jason R.]

On Tue, 22 May 2001, Shannon Hendrix wrote:

> On Tue, May 22, 2001 at 02:49:21PM -0400, Jason Andresen wrote:
>
> > 6 files took ~15 minutes to create as is.  I'm going to have to wait
> > until tonight to run larger sets.  2.2.16 is what we have here.
> > I'm still waiting to see how much faster ReiserFS is.
>
> I'm willing to overnight your test if you want. Do you have it packaged
> up to send? It would be interesting just to get numbers from a Linux
> system with a modern kernel. 2.4.1 gave me enough of a speed boost to
> put off another FreeBSD install until I fix some problems there.
>
> I cannot test FreeBSD with SCSI right now so my system will be an
> inequal set of results.
>
> I would offer to test NetBSD as well, but I suppose no one would be
> interested in that.

The test is 'postmark'.  It is in /usr/ports/benchmarks, but the
distribution is a single C file.  Just compile it with:
gcc -O -o postmark postmark.c on all of the systems.  That's what the port
uses.  Your system should be unladen but running in multiuser mode and the
test directory you choose should be empty.

The options you are interested in are:
set transactions 1 <-- What I used for all of my tests
set number 
set location /path/to/empty/local/directory
run



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

Re: technical comparison

[Andresen,Jason R.]

I just finished the FreeBSD test with

vfs.vmiodirenable=1 (it was 0 before)

6 simlultanious files, 1 transactions, FreeBSD
4.0-Release+Softupdates with write cacheing disabled.  Results are pretty
much unchanged.  Do you have to enable vmiodirenable at boot time for it
to take affect?

Time:
1286 seconds total
505 seconds of transactions (19 per second)

Files:
65065 created (50 per second)
Creation alone: 6 files (85 per second)
Mixed with transactions: 5065 files (10 per second)
5078 read (10 per second)
4921 appended (9 per second)
65065 deleted (50 per second)
Deletion alone: 60130 files (761 per second)
Mixed with transactions: 4935 files (9 per second)

Data:
26.01 megabytes read (20.23 kilobytes per second)
325.12 megabytes written (252.82 kilobytes per second)



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

Re: technical comparison

[Andresen,Jason R.]

On Tue, 22 May 2001, Terry Lambert wrote:

> I don't understand the inability to perform the trivial
> design engineering necessary to keep from needing to put
> 60,000 files in one directory.
>
> However, we can take it as a given that people who need
> to do this are incapable of doing computer science.
>
> I would suggest two things:
>
> 1)If write caching is off on the Linux disks, turn
>   it off on the FreeBSD disks.
>
> 2)"  " -- and then turn it on on both.
>
> 3)Modify the test to delete the files based on a
>   directory traversal, instead of promiscuous
>   knowledge of the file names, which is cheating
>   to make the lookups appear faster.
>
> (the rationale behind this last is that people who can't
> design around needing 60,000 files in a single directory
> are probably going to to be unable to correctly remember
> the names of the files they created, since if they could,
> then they could remember things like ./a/a/aardvark or
> ./a/b/abominable).

The problem comes along when you are using a third party
application that keeps a bazillion files in a directory,
which was the problem that spawned this entire thread.

Why is knowing the file names cheating?  It is almost certain
that the application will know the names of it's own files
(and won't be grepping the entire directory every time it
needs to find a file).  I doubt a human is ever going to want
to work in a directory where you have 6 files lying about,
but an application might easily be written to work in just such
conditions.


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

Re: technical comparison

[Andresen,Jason R.]

On Tue, 22 May 2001, Shannon Hendrix wrote:

> On Tue, May 22, 2001 at 12:03:33PM -0400, Jason Andresen wrote:
>
> > The data:
> >
> > Hardware:
> > Both machines have the same hardware on paper (although it is TWO
> > machines,
> > YMMV).
> > PII-300
> > Intel PIIX4 ATA33 controller
> > IBM-DHEA-38451 8063MB ata0-master using UDMA33 HD
> >
> > Note: all variables are left at default unless mentioned.
> >
> > 1 transactions, 500 files.
>
> What did you set size to?  How much memory on the machine?

Size was left at the default.  The machines have 64MB of main memory.



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

Re: ppp problems on 4.3-RELEASE and PPPoE

[Brian Somers]

Hmm,

I wonder if you can catch it again and do a ``set log local 
physical'' and run ``tcpdump -i XXX -e not ip'' on the interface at 
the same time ?

A ``ping -c 1'' should then show if ppp's sending the data out, and 
if it is, if ng_ether is forwarding it.

I'm a little concerned about the MRU of 1500 too.  The peer seems 
broken.  I have patches to fix this, but they've been paid for as 
part of another project so will have to wait 'till the source is 
released.  If the ping packet goes out but nothing comes back it may 
indicate that the peer is hung up trying to send a 1500+8 byte packet 
across an Ethernet that can only handle 1500

> According to Brian Somers:
> > If pppctl is still working (ppp will talk to it), then it may be 
> > worth seeing what ``show physical'' and ``show timer'' say (is the 
> > link open, or is ppp waiting for something to happen via a timeout?).
> 
> Locked again with a pppctl attached.
> 
> show timer
> -=-=-
> IPCP throughput timer[0x80a37d8]: freq = 1.00s, next = 0.00s, state = running
> physical throughput timer[0x80af068]: freq = 1.00s, next = 0.90s, state = running
> hdlc timer[0x80b1d84]: freq = 60.00s, next = 22.90s, state = running
> -=-=-
> 
> show physical
> -=-=-
> Name: deflink
>  State:   open (established)
>  Device:  PPPoE:ed0:
>  Link Type:   background
>  Connect Count:   1
>  Queued Packets:  0
>  Phone Number:N/A
> 
> Defaults:
>  Device List: "PPPoE:ed0:"
>  Characteristics: sync, cs8, no parity, CTS/RTS on
>  CD check delay:  device specific
> 
> Connect time: 24:08:11
> 14864337 octets in, 8655370 octets out
> 56740 packets in, 56238 packets out
>   overall  270 bytes/sec
>   currently  0 bytes/sec in,  0 bytes/sec out (over the last 5 secs)
>   peak   70148 bytes/sec on Mon May 21 20:02:16 2001
> -=-=-
> 
> show lcp
> -=-=-
> PPP ON keltia> show lcp
> deflink: LCP [Opened]
>  his side: MRU 1492, ACCMAP , PROTOCOMP off, ACFCOMP off,
>MAGIC 6317ffaa, MRRU 0, SHORTSEQ off, REJECT 
>  my  side: MRU 1500, ACCMAP , PROTOCOMP off, ACFCOMP off,
>MAGIC 0c7a6a1f, MRRU 0, SHORTSEQ on, REJECT 
> 
>  Defaults: MRU = 1492, ACCMAP = 
>LQR period = 30s, Open Mode = active (delay 1s)
>FSM retry = 3s, max 5 Config REQs, 5 Term REQs
> Ident: 
> 
>  Negotiation:
>ACFCOMP =   disabled & denied
>CHAP =  disabled & accepted
>CHAP80 =disabled & accepted
>LANMan =disabled & accepted
>CHAP81 =disabled & accepted
>LQR =   disabled & denied
>PAP =   disabled & accepted
>PROTOCOMP = disabled & accepted
> -=-=-
> 
> -- 
> Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- [EMAIL PROTECTED]
> FreeBSD keltia.freenix.fr 5.0-CURRENT #80: Sun Jun  4 22:44:19 CEST 2000

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

Re: technical comparison

[Shannon Hendrix]

On Wed, May 23, 2001 at 06:53:37AM -0300, Daniel C. Sobral wrote:

> > I cannot verify that with my drive, but my largest is 18GB so maybe
> > the difference is not as pronounced as on some newer drives like those
> > (currently) monster 70GB drives.
> 
> It should be measurable.

Actually, I edited too much.  I have seen a difference, but it was too small
to care abot on my system.  These are 7200rpm 18GB drives too.

The other variances in filesystem performance seem to overshadow the
difference.

The only thing I ever did to pick up some speed was to move some data
on a raw device to the faster tracks. I was streaming it in so the
speedup was good. I also picked up some performance on one Linux system
by putting swap in the faster tracks. But for the most part, I've never
been able to tell.

I have read that on the 40-80GB drives, it's very noticeable. In fact,
the IBM Ultrastars are supposed to be faster than their electronics can
handle on the very outer tracks.

-- 
 "Secrecy is the beginning of tyranny." -- Unknown   | | |
 | | |
/  |  \
s h a n n o n @ w i d o m a k e r . c o m _/   |   \_

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

Re: technical comparison

[julien]

Hi all,

I tried your tests on a quite different configuration, a PIII 800 with
1GB ram, with an AcceleRAID 170 controller and a single RAID5 pack of
4*8GB IBM SCSI drives. The system is a 4.3-rc2, NO softupdates, default
configuration.
Here are the results :

pm>set transactions 1
pm>set number 6
pm>set location /root/test/
pm>run
Creating files...Done
Performing transactions..Done
Deleting files...Done
Time:
1715 seconds total
199 seconds of transactions (50 per second)

Files:
65065 created (37 per second)
Creation alone: 6 files (73 per second)
Mixed with transactions: 5065 files (25 per second)
5078 read (25 per second)
4921 appended (24 per second)
65065 deleted (37 per second)
Deletion alone: 60130 files (86 per second)
Mixed with transactions: 4935 files (24 per second)

Data:
26.01 megabytes read (15.17 kilobytes per second)
325.12 megabytes written (189.58 kilobytes per second)

--
---
--> [EMAIL PROTECTED]
---

- Original Message -
From: "Andresen,Jason R." <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, May 23, 2001 3:15 PM
Subject: Re: technical comparison


> I just finished the FreeBSD test with
>
> vfs.vmiodirenable=1 (it was 0 before)
>
> 6 simlultanious files, 1 transactions, FreeBSD
> 4.0-Release+Softupdates with write cacheing disabled.  Results are
pretty
> much unchanged.  Do you have to enable vmiodirenable at boot time for
it
> to take affect?
>
> Time:
> 1286 seconds total
> 505 seconds of transactions (19 per second)
>
> Files:
> 65065 created (50 per second)
> Creation alone: 6 files (85 per second)
> Mixed with transactions: 5065 files (10 per second)
> 5078 read (10 per second)
> 4921 appended (9 per second)
> 65065 deleted (50 per second)
> Deletion alone: 60130 files (761 per second)
> Mixed with transactions: 4935 files (9 per second)
>
> Data:
> 26.01 megabytes read (20.23 kilobytes per second)
> 325.12 megabytes written (252.82 kilobytes per second)
>
>
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-hackers" in the body of the message
>


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

Re: technical comparison

[Shannon Hendrix]

On Wed, May 23, 2001 at 09:03:37AM -0400, Andresen,Jason R. wrote:

> The scary thing is that it was the attached harddrive that lost all of the
> files.  The situitation is this:
[snip]

Sorry to hear that, but like I said, it isn't typical. ext2 in it's
early days, an ext before that were really bad. But I have few problems
with it these days. I've lost more ufs filesystems than I have ext2, but
I don't assume my results are typical: I know ufs is better. However,
ext2's problems are grossly exaggerated. 

> It's entirely possible that there is something I could have done to
> prevent fsck from clearing out the filesystem, but it certainly isn't
> obvious from the manual, and I've never seen a FreeBSD system do that.

Nothing much you can do unless you happen to know ext2 inside and out,
and fix it manually.

It's not normal for ext2 to die like that, and be unable to recover. 

Over the years I have had more bizarre, inexplicable OS problems on
Intel PCs than any other.

> Also, for anybody who says the pull the power test isn't realistic, I can
> assure you that power failures DO happen (probably less in your area than

My point was that yanking power only tests one aspect of the filesystem.
Chosing one based on passing or not passing that test isn't a good idea.

> mine (I hope!)) and not planning for them only brings disaster later when
> you have a room with 1000 servers lose power.

Well, a UPS system is as important in any system you care about as the
computers and operating systems. If you run 1000 servers and they can
lose power, you're on borrowed time anyway.

Where I live, the power gets worse every year. I lost quite a few ext
filesystems, but only a couple of ufs and ext2 filesystems. Then I
bought a 1920VA UPS and it's no longer an issue. I just found it easier
to not lose power than to worry about which filesystem recovers from it
better.

-- 
"There are nowadays professors of philosophy, but not philosophers."

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

Re: Device driver questions

[Julian Elischer]

Alexander Langer wrote:
> 
> Thus spake SJ ([EMAIL PROTECTED]):
>
> 
> The developer's handbook might be worth reading for you, also there
> are some tutorials on the website which explain a little.

Also check out -current's /usr/share/examples/drivers/make_device_driver.sh

> 
> Alex
> 
> --
> cat: /home/alex/.sig: No such file or directory
> 
> 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: technical comparison

[D. Rock]

Zitiere "Daniel C. Sobral" <[EMAIL PROTECTED]>:

> Note, though, that there is some very recent perfomance improvement on
> very large directories known as dirpref (what changed, actually, was
> dirpref's algorithm). This is NOT present on 4.3-RELEASE, though it
> _might_ have since been committed to stable.
I don't think dirpref should help in this case.

IIRC the dirpref patches change the algorithm choosing the cg of subdirectories
relative to their parent. Since postmark by default only uses one directory,
there should be no benefit.

-- 
Daniel

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

removing inb()/outb() from devices

[j mckitrick]

I'd like to finalize the newbus work by changing inb()/outb() calls to
bus_space_write calls.  Is there a device where this has been partially done
already?  I'd like to see the old and new styles, then i would fix the
vpo/imm zip driver first, since i know that code well.  After that, i could
start working my way through the tree.

jcm
-- 
"I drank WHAT ?!" - Socrates

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

Re: technical comparison

[Andresen,Jason R.]

On Wed, 23 May 2001, Shannon Hendrix wrote:

> Where I live, the power gets worse every year. I lost quite a few ext
> filesystems, but only a couple of ufs and ext2 filesystems. Then I
> bought a 1920VA UPS and it's no longer an issue. I just found it easier
> to not lose power than to worry about which filesystem recovers from it
> better.

One of the funny things about the place I used to work (which will remain
unnamed) was how the UPS folks were always testing their systems by
pulling the plug on the main power to the building.  The problem was they
apparently hired untrained monkeys to wire up the UPS systems (which were
just a few rooms chock full of batteries) and managed to kill power to the
entire building (including the computer rooms) at least once every three
months.  This was doubly annoying because we had well over 100 full RAID
racks (with 80 disks in each rack) in the facility.  Hard drives, as most
of you probablly know, are most likly to fail on boot time, so every time
one of the brain cases managed to kill the power in the CRs, we had to
spend the rest of the day replacing failed RAID drives.


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

Re: technical comparison

[Kris Kennaway]

On Wed, May 23, 2001 at 08:17:12AM -0400, Andresen,Jason R. wrote:

> > Did you enable write caching?  You didn't mention, and it's off by
> > default in 4.3, but I think enabled by default on Linux.
> 
> I tried to leave the FreeBSD and Linux boxes as unchanged as possible for
> my tests (they are lab machines that have other uses, although I made sure
> they were idle during the test periods).
> 
> I left write caching enabled in the Linux boxes, and left it disabled on
> the FreeBSD boxes.  Personally, I'm hesitant to enable write caching
> on FreeBSD because we tend to use it on machines where we really really
> don't want to lose data.  Write caching is ok on the Linux machines
> because we use them as pure testbeds that we can reconstruct easily if
> their disks go south.

That's all well and good, but I thought the aim here was to compare
Linux and FreeBSD performance on as level playing field as possible?
You're not measuring FS performance, you're measuring FS performance
plus cache performance, so your numbers so far tell you nothing
concrete.

Kris

 PGP signature

Re: removing inb()/outb() from devices

[Alexander Langer]

Thus spake j mckitrick ([EMAIL PROTECTED]):

> I'd like to finalize the newbus work by changing inb()/outb() calls to
> bus_space_write calls.  Is there a device where this has been partially done
> already?  I'd like to see the old and new styles, then i would fix the

It has been done to sys/dev/ed/ about half a year ago.

Alex
-- 
cat: /home/alex/.sig: No such file or directory

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

Re: ppp problems on 4.3-RELEASE and PPPoE

[Ollivier Robert]

According to Brian Somers:
> Brett Glass (cc'd) has complained about a similar problem where it 
> seems that the ng_pppoe node is locked up.  I can't reproduce the 
> problem here though :(

Does the following help you :

-=-=-
tun0: Timer:  Begin of Timer Service List---
tun0: Timer: physical throughput timer[0x80af068]: freq = 1.00s, next = 0.00s, state = 
running
tun0: Timer: IPCP throughput timer[0x80a37d8]: freq = 1.00s, next = 0.60s, state = 
running
tun0: Timer: hdlc timer[0x80b1d84]: freq = 60.00s, next = 55.50s, state = running
tun0: Timer:  End of Timer Service List ---
tun0: Timer: timer_Start: Inserting physical throughput timer[0x80af068] before hdlc 
timer[0x80b1d84], delta = 4
tun0: Timer: tun: fdset(r) 3
tun0: Timer: deflink(ctrl): fdset(r) 0
tun0: Timer: deflink: fdset(r) 1
tun0: Timer: deflink: fdset(e) 1
tun0: Timer: server: fdset(r) 6
tun0: Timer: prompt 127.0.0.1:60676: fdset(r) 2
tun0: Timer: Select returns -1
tun0: Timer: timer_Start: Inserting IPCP throughput timer[0x80a37d8] before hdlc 
timer[0x80b1d84], delta = 6
tun0: Timer: tun: fdset(r) 3
tun0: Timer: deflink(ctrl): fdset(r) 0
tun0: Timer: deflink: fdset(r) 1
tun0: Timer: deflink: fdset(e) 1
tun0: Timer: server: fdset(r) 6
tun0: Timer: prompt 127.0.0.1:60676: fdset(r) 2
tun0: Timer: Select returns -1
tun0: Timer:  Begin of Timer Service List---
tun0: Timer: physical throughput timer[0x80af068]: freq = 1.00s, next = 0.00s, state = 
running
tun0: Timer: IPCP throughput timer[0x80a37d8]: freq = 1.00s, next = 0.60s, state = 
running
tun0: Timer: hdlc timer[0x80b1d84]: freq = 60.00s, next = 54.50s, state = running
tun0: Timer:  End of Timer Service List ---
tun0: Timer: timer_Start: Inserting physical throughput timer[0x80af068] before hdlc 
timer[0x80b1d84], delta = 4
tun0: Timer: tun: fdset(r) 3
tun0: Timer: deflink(ctrl): fdset(r) 0
tun0: Timer: deflink: fdset(r) 1
tun0: Timer: deflink: fdset(e) 1
tun0: Timer: server: fdset(r) 6
tun0: Timer: prompt 127.0.0.1:60676: fdset(r) 2
tun0: Timer: Select returns -1
tun0: Timer: timer_Start: Inserting IPCP throughput timer[0x80a37d8] before hdlc 
timer[0x80b1d84], delta = 6
tun0: Timer: tun: fdset(r) 3
tun0: Timer: deflink(ctrl): fdset(r) 0
tun0: Timer: deflink: fdset(r) 1
tun0: Timer: deflink: fdset(e) 1
tun0: Timer: server: fdset(r) 6
tun0: Timer: prompt 127.0.0.1:60676: fdset(r) 2
tun0: Timer: Select returns -1
tun0: Timer:  Begin of Timer Service List---
tun0: Timer: physical throughput timer[0x80af068]: freq = 1.00s, next = 0.00s, state = 
running
tun0: Timer: IPCP throughput timer[0x80a37d8]: freq = 1.00s, next = 0.60s, state = 
running
tun0: Timer: hdlc timer[0x80b1d84]: freq = 60.00s, next = 53.50s, state = running
tun0: Timer:  End of Timer Service List ---
tun0: Timer: timer_Start: Inserting physical throughput timer[0x80af068] before hdlc 
timer[0x80b1d84], delta = 4
tun0: Timer: tun: fdset(r) 3
tun0: Timer: deflink(ctrl): fdset(r) 0
tun0: Timer: deflink: fdset(r) 1
tun0: Timer: deflink: fdset(e) 1
tun0: Timer: server: fdset(r) 6
tun0: Timer: prompt 127.0.0.1:60676: fdset(r) 2
stun0: Timer: Select returns -1
etun0: Timer: timer_Start: Inserting IPCP throughput timer[0x80a37d8] before hdlc 
timer[0x80b1d84], delta = 6
tun0: Timer: tun: fdset(r) 3
tun0: Timer: deflink(ctrl): fdset(r) 0
tun0: Timer: deflink: fdset(r) 1
tun0: Timer: deflink: fdset(e) 1
tun0: Timer: server: fdset(r) 6
tun0: Timer: prompt 127.0.0.1:60676: fdset(r) 2
ttun0: Timer: Select returns -1
tun0: Timer:  Begin of Timer Service List---
tun0: Timer: physical throughput timer[0x80af068]: freq = 1.00s, next = 0.00s, state = 
running
tun0: Timer: IPCP throughput timer[0x80a37d8]: freq = 1.00s, next = 0.60s, state = 
running
tun0: Timer: hdlc timer[0x80b1d84]: freq = 60.00s, next = 52.50s, state = running
tun0: Timer:  End of Timer Service List ---
tun0: Timer: timer_Start: Inserting physical throughput timer[0x80af068] before hdlc 
timer[0x80b1d84], delta = 4
tun0: Timer: tun: fdset(r) 3
tun0: Timer: deflink(ctrl): fdset(r) 0
tun0: Timer: deflink: fdset(r) 1
tun0: Timer: deflink: fdset(e) 1
tun0: Timer: server: fdset(r) 6
tun0: Timer: prompt 127.0.0.1:60676: fdset(r) 2
 tun0: Timer: Select returns -1
tun0: Timer: timer_Start: Inserting IPCP throughput timer[0x80a37d8] before hdlc 
timer[0x80b1d84], delta = 6
tun0: Timer: tun: fdset(r) 3
tun0: Timer: deflink(ctrl): fdset(r) 0
tun0: Timer: deflink: fdset(r) 1
tun0: Timer: deflink: fdset(e) 1
tun0: Timer: server: fdset(r) 6
tun0: Timer: prompt 127.0.0.1:60676: fdset(r) 2
-=-=- 

Nothing really interesting from 'tcpdump -n -i ed0 not ip'...
-- 
Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- [EMAIL PROTECTED]
FreeBSD keltia.freenix.fr 5.0-CURRENT #80: Sun Jun  4 22:44:19 CEST 2000

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

Re: ppp problems on 4.3-RELEASE and PPPoE

[Brian Somers]

> According to Brian Somers:
> > Brett Glass (cc'd) has complained about a similar problem where it 
> > seems that the ng_pppoe node is locked up.  I can't reproduce the 
> > problem here though :(
> 
> Does the following help you :
[.]

Not really - I think we need ``physical'' logs so that we can see if 
stuff is actually being written to the netgraph node.  The ``timer'' 
diagnostics are too verbose to be of use here.

The idea is to do the ``ping -c1'', and if everything were working, 
see the physical log show the packet being written to netgraph and 
then netgraph putting it on the wire.

> Nothing really interesting from 'tcpdump -n -i ed0 not ip'...

As in nothing at all ?  I wonder what the last ``not ip'' traffic to be 
written was - perhaps the netgraph node thinks it's closed.

> -- 
> Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- [EMAIL PROTECTED]
> FreeBSD keltia.freenix.fr 5.0-CURRENT #80: Sun Jun  4 22:44:19 CEST 2000

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

Re: Device driver questions

[SJ]

--- Alexander Langer <[EMAIL PROTECTED]> wrote:
> Thus spake SJ ([EMAIL PROTECTED]):
> 
> Hi!
> 
> > 1. "ioconf.c" contains struct config_resource and
> > config_device definitions for declarations in 
> > "config" file. But I noticed that for some
> devices
> >  e.g. device  atadisk
> >   device  atapicd
> >   ...
> >  the corresponding lines in ioconf.c are
> missing??
> 
> I think it's because ata is a self-identifying bus.
> Not sure, though.  Are any PCI-only devices listed?

The configuration contains the following two lines:
device  pci0
device  pci1
for which the corresponding ioconf.c output is:
struct config_resource pci0_resources[] = {
};
#define pci0_count 0
struct config_resource pci1_resources[] = {
};
#define pci1_count 0

> 
> > 3. File naming question:
> >whats the reasoning behind having "bus.h" and 
> >"bus_private.h"whats the significance of 
> >"private" here.
> 
> drivers include bus.h, kernel does also include
> bus_private.h

But still the name "private" confuses me...according
to
me it should have been "bus_public.c". Any comments?

thanks for your help
sandeep

> 
> > 4. concept behind having devclasses...I know that 
>  
> >devclasses for a particular bus holds devices
> and
> >device drivers for that bus. But then whats the
>  
> >need for defining a devclass for each driver we
> 
> >write ?
> 
> Because you can hold multpiple devices that are
> enumerated, e.g. xl0,
> xl1, ...
> The devclass is unique for each driver, but not for
> different busses.
> You can have ed0 on ISA and ed1 on PCI for example,
> using the same
> devclass.
> If ISA and PCI subdrivers are using a different
> devclass, the
> enumeration breaks.
> 
> > 5. Any poniters to literature which explains the 
> >design philosophy and code specific help for
> device
> >drivers in freebsd - I am referring to files 
> >kern/subr_bus.c, bus.h, bus_private.h, isa/*
> etc.
> 
> Use the source, luke :-)
> Seriously, subr_bus.c is quite nice to read if you
> read it togethers
> with, say, sys/pci/pci.c.
> That makes the concept quite clear.
> 
> The developer's handbook might be worth reading for
> you, also there
> are some tutorials on the website which explain a
> little.
> 
> Alex
> 
> -- 
> cat: /home/alex/.sig: No such file or directory


__
Do You Yahoo!?
Yahoo! Auctions - buy the things you want at great prices
http://auctions.yahoo.com/

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

Re: technical comparison

[Andresen,Jason R.]

On Wed, 23 May 2001, Kris Kennaway wrote:

> On Wed, May 23, 2001 at 08:17:12AM -0400, Andresen,Jason R. wrote:
>
> > > Did you enable write caching?  You didn't mention, and it's off by
> > > default in 4.3, but I think enabled by default on Linux.
> >
> > I tried to leave the FreeBSD and Linux boxes as unchanged as possible for
> > my tests (they are lab machines that have other uses, although I made sure
> > they were idle during the test periods).
> >
> > I left write caching enabled in the Linux boxes, and left it disabled on
> > the FreeBSD boxes.  Personally, I'm hesitant to enable write caching
> > on FreeBSD because we tend to use it on machines where we really really
> > don't want to lose data.  Write caching is ok on the Linux machines
> > because we use them as pure testbeds that we can reconstruct easily if
> > their disks go south.
>
> That's all well and good, but I thought the aim here was to compare
> Linux and FreeBSD performance on as level playing field as possible?
> You're not measuring FS performance, you're measuring FS performance
> plus cache performance, so your numbers so far tell you nothing
> concrete.

Yes, they tell us that FreeBSD with softupdates and no write cache
performs better in large cases than Linux with ext2fs and write caching
enabled.

Also my FreeBSD 4.0 boxes don't have the hw.ata.wc knob, so it's harder
for me to test this.  Also, I don't know how ones goes about disabling the
write cache in Linux without recompiling the kernel (which we have some
custom mods in place, so I'm reluctant to do this).


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

Re: removing inb()/outb() from devices

[j mckitrick]

On Wed, May 23, 2001 at 07:04:15PM +0200, Alexander Langer wrote:
| Thus spake j mckitrick ([EMAIL PROTECTED]):
| 
| > I'd like to finalize the newbus work by changing inb()/outb() calls to
| > bus_space_write calls.  Is there a device where this has been partially done
| > already?  I'd like to see the old and new styles, then i would fix the
| 
| It has been done to sys/dev/ed/ about half a year ago.

Found it!  Thanks.



jcm
-- 
"I drank WHAT ?!" - Socrates

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

Re: technical comparison

[Bsdguru]

Tell them to fire 20K packets/second at the linux box and watch it crumble. 
Linux has lots of little kludges to make it appear faster on some benchmarks, 
but from a networking standpoint it cant handle significant network loads.

Bryan

> > Hi,
>  >
>  > I appoligize if this is the improper channel for this sort of
>  >discussion, but it is in the best interests of the FreeBSD following,
>  >atleast, within my orginization.
>  >
>  > I work in an environment consisting of 300+ systems, all FreeBSD
>  >and Solaris, along with lots of EMC and F5 stuff. Our engineering division
>  >has been working on a dynamic content server and search engine for the
>  >past 2.5 years. They have consistently not met up to performance and
>  >throughput requirements and have always blamed our use of FreeBSD for it.
>  >We have humored them time and time again; i.e. they once claimed the lack
>  >of some sort of RAID was keeping them from meeting their requirements,
>  >when he had already thrown brute amounts of hardware at their application.
>  >When we setup a load-testing environment with multiple types of RAIDs, all
>  >the systems, including the one without any sort of RAID performed
>  >identically. And poorly, at that.
>  >
>  > We have had a recent change in departmental structure, which
>  >unfortunately, weakened the more technical side of the top of the food
>  >chain. They have taken this as another opportunity to push for Linux-use
>  >within our environment. We do not want, nor feel the need for introducing
>  >another OS into the environment.
>  >
>  > The following are the points that the head of engineering claimed
>  >were their requirements and our shortcoming, which Linux would handle
>  >well:
>  >
>  >---
>  >
>  >a) A machine that has fast character operations
>  >
>  >b) A *supported* Oracle client
>  >
>  >c) A filesystem that will be fast in light of tens of thousands of
>  >files in a single directory (maybe even hundreds of thousands)
>  >
>  >Requirement a) means that it won't run well on a Sparc processor as
>  >they are notoriously bad at character addressing, and since search
>  >makes extensive use of character operations (as does *any* web
>  >application server for that matter), using a Sparc processor will be a
>  >waste since the x86 architecture (AMD's and Crusoe's especially) do it
>  >much better.
>  >
>  >Requirement b) means it won't be FreeBSD.  Yes, you can run Linux apps
>  >under emulation, but I'd bet dollars for doughnuts that this will be a
>  >support nightmare if we can even get it to work.
>  >
>  >Requirement c) means it won't be Solaris or FreeBSD since neither of
>  >them have a filesystem which handles this effectively.
>  >
>  >Linux on Intel fits the bill because it meets these three requirements
>  >*very* effectively.
>  >
>  >---
>  >
>  > I find them to be mostly silly points -- (a) touching on integer
>  >math -- pretty moot point given the real meat of this. (b) is wrong, since
>  >there is a native port of the oracle client and (c) is just silly -- I'm
>  >sure softupdates on a modern BSD ufs is loads faster than ext2fs.
>  >
>  > Folks, please give me some real technical ammo -- reference
>  >internals, give a real technical comparison if possible. I don't believe
>  >this is some lame FreeBSD/Linux comparison -- I'm simply trying to
>  >tactfully and effectively deal with a zealot. :-)
>  >
>  > Any help would be greatly appreciated.
>  >
>  > -charles.

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

Re: technical comparison

[Andresen,Jason R.]

On Wed, 23 May 2001 [EMAIL PROTECTED] wrote:

>
> Tell them to fire 20K packets/second at the linux box and watch it crumble.
> Linux has lots of little kludges to make it appear faster on some benchmarks,
> but from a networking standpoint it cant handle significant network loads.
>
Are you sure this is still true?  The 2.4.x series kernel was supposed to
have significant networking improvements over the previous kernels.


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

Re: -R for make update ?

[Wilko Bulte]

On Tue, May 22, 2001 at 02:42:42PM -0700, Kris Kennaway wrote:
> On Tue, May 22, 2001 at 02:15:18PM -0600, Nate Williams wrote:
> > > > > Is there any specific reason why one needs to be able to
> > > > > write a lock to the CVS repo when running 'make update'
> > > > > to get a freshly checked out source?
> > > > 
> > > > Yeah: you aren't running your CVS server in "pserver"
> > > > mode, and so are trying to do a lock, either in your
> > > > local copy, or over NFS.
> > > > 
> > > > If you run your repository in pserver mode, the CVS server
> > > > will be connected to over the network, instead of attacking
> > > > your CVS repo directly, and you won't have the problem you
> > > > are seeing, since the cvs server will be able to get the
> > > > lock, no problem.
> > > 
> > > It will also be freakishly slow, and use massive amounts of temp
> > > space.
> > 
> > No slower than cvs using rsh/ssh, although it does tend to create alot
> > of inodes in /tmp.  (It doesn't create alot of temp space, other than
> > what is used to create the directories...)
> 
> Yes, using rsh/ssh is also slow, but we were talking about *local*
> access, which has none of those drawbacks.  -R makes cvs operations go

Yes, this is a local repo indeed.

> quite a bit faster, and AFAIK is perfectly safe if you're using a
> private repo for which you know there will be no contention.

W/
-- 
|   / o / /  _   Arnhem, The Netherlandsemail: [EMAIL PROTECTED]
|/|/ / / /( (_) BultePowered by FreeBSD/alpha   http://www.freebsd.org  

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

panics with 4GB on an IBM xSeries 330

[Nadav Eiron]

Hi all,

We have a 4GB IBM xSeries 330 (1GHz PIII) and I can't get 4.3-RELEASE to
boot on it. I did set NKPT to 64 as suggested by DG about a week ago on
this list (this is also the reason I take this to -hackers rather than
-questions). Still, I get 
panic: swap_pager_swap_init: swap_zone=NULL
when booting (both the modified kernel and GENERIC behave the same). An
identical machine with 1GB works like a champ. Anything else other than
NKPT I should set?

Thanks for any and all comments,
Nadav


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

telnet to AF_UNIX sockets [PATCH]

[Lyndon Nerenberg]

A few months back I taught telnet about named sockets. We've found this
very useful for testing things like IPC channels in our software
(e.g. telnet /var/run/lmtp). I've put the (-STABLE) patches up at:

 ftp://orthanc.ab.ca/lyndon/freebsd/telnet.AF_UNIX.patch

If someone with commit priv's thinks this is worth including, be
my guest.

--lyndon

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

Re: telnet to AF_UNIX sockets [PATCH]

[Alfred Perlstein]

* Lyndon Nerenberg <[EMAIL PROTECTED]> [010523 18:22] wrote:
> A few months back I taught telnet about named sockets. We've found this
> very useful for testing things like IPC channels in our software
> (e.g. telnet /var/run/lmtp). I've put the (-STABLE) patches up at:
> 
>  ftp://orthanc.ab.ca/lyndon/freebsd/telnet.AF_UNIX.patch
> 
> If someone with commit priv's thinks this is worth including, be
> my guest.

This is really cool, can you submit it as a PR?

-- 
-Alfred Perlstein [[EMAIL PROTECTED]]
Instead of asking why a piece of software is using "1970s technology,"
start asking why software is ignoring 30 years of accumulated wisdom.

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

Re: telnet to AF_UNIX sockets [PATCH]

[Matt Dillon]

:A few months back I taught telnet about named sockets. We've found this
:very useful for testing things like IPC channels in our software
:(e.g. telnet /var/run/lmtp). I've put the (-STABLE) patches up at:
:
: ftp://orthanc.ab.ca/lyndon/freebsd/telnet.AF_UNIX.patch
:
:If someone with commit priv's thinks this is worth including, be
:my guest.
:
:--lyndon

Hey great!  I love it.  I'll commit it, but could we change the -/ option
to -u or -U or something like that?  Any preferences?

-Matt

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

Re: telnet to AF_UNIX sockets [PATCH]

[Matt Dillon]

:>  ftp://orthanc.ab.ca/lyndon/freebsd/telnet.AF_UNIX.patch
:> 
:> If someone with commit priv's thinks this is worth including, be
:> my guest.
:
:This is really cool, can you submit it as a PR?
:
:-- 
:-Alfred Perlstein [[EMAIL PROTECTED]]

Don't bother, I'll commit it right now as soon as I get an OK for 
turning -/ into -u.

-Matt

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

Re: telnet to AF_UNIX sockets [PATCH]

[Matt Dillon]

I've committed the patch, changing -/ to -u (note: you don't need the 
option at all if you specify a path beginning with '/', as per Lyndon's
original code), to current (both non-crypto and crypto versions).  I
will MFC it to stable in three days.

Nice one!  I'm going to be using this all over the place myself.

-Matt

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

Seeking recommendations for backup system

[sthaug]

I'm seeking recommendation for a backup system (software) that can be
used with a decent sized tape library, probably LTO based, and FreeBSD
4.3-STABLE.

I'm sure we could roll our based on freely available tools (eg. Amanda)
- but by now I'm used to Tivoli ADSM/TSM, and *like* the convenience
ADSM/TSM offers.  We need the ability to make backups (via Fast Ethernet)
primarily of FreeBSD servers, but also Solaris, Linux and HP-UX. Easy
restore is important.

(So why not buy TSM again? Primarily the price. We'll do it if we have to,
but would prefer something slightly less expensive and also less complex.)

Any takers?

Steinar Haug, Nethelp consulting, [EMAIL PROTECTED]

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

Re: technical comparison

[void]

On Wed, May 23, 2001 at 09:20:51AM -0400, Andresen,Jason R. wrote:
> 
> Why is knowing the file names cheating?  It is almost certain
> that the application will know the names of it's own files
> (and won't be grepping the entire directory every time it
> needs to find a file).

With 60,000 files, that would have the application duplicating
60,000 pieces of information that are stored by the operating system.
Operations like open() and unlink() still have to search the directory
to get the inode, so there isn't much incentive for an application to
do that, I think.

-- 
 Ben

"An art scene of delight
 I created this to be ..."  -- Sun Ra

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

Re: technical comparison

[Dave Hayes]

Terry Lambert <[EMAIL PROTECTED]> writes:
> I don't understand the inability to perform the trivial
> design engineering necessary to keep from needing to put
> 60,000 files in one directory.

Hear hear! ;) (Been waiting for that one)

> However, we can take it as a given that people who need
> to do this are incapable of doing computer science.

You can't make that assumption just yet (although it seems
reasonable). We really don't know exactly what the problem they are
trying to solve is. Network news sites running old versions of
software (as an example, I know someone who still runs CNEWS) have
very clear reasons for phenomena resembling 60,000 files in one
directory.

I would begin to question the assumption that seems to have been
unquestioned. Namely, why is the focus -just- on speed? FreeBSD
outperforms Linux on reliability and security as well. Not to mention
networking. 
--
Dave Hayes - Consultant - Altadena CA, USA - [EMAIL PROTECTED] 
>>> The opinions expressed above are entirely my own <<<

We can never have enough of that which we really do not want.  --Eric Hoffer





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

Re: telnet to AF_UNIX sockets [PATCH]

[Joseph A. Mallett]

Looking at the patch, is it safe to assume that if there's a '/' in a
hostname, it MUST be a AF_UNIX socket? If so, wouldn't a strchr(hostp,
'/') be better than 'hostp[0] == '/''? This way one can use relative paths
as well, not just absolute ones.

--
[ Joseph Mallett<[EMAIL PROTECTED]> ] [ http://srcsys.org ]
[ xMach Core Team xMach: Proactively Unbloated Microkernel BSD ]
[ FreeBSD, NetBSD, & xMach User; (Obj)C(++) Coder ] [ http://xMach.org ]

-BEGIN GEEK CODE BLOCK-
Version: 3.12
GCS d-- s+:++ a--- C+++ UB P+++ L- E W++ N+ o-- K- w++
O M+ V PS+ PE- Y+ PGP++ t++ 5-- X+ R tv- b++ DI+ D---
G e* h! r% z+
--END GEEK CODE BLOCK--


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

Re: telnet to AF_UNIX sockets [PATCH]

[James Howard]

On Wed, 23 May 2001, Matt Dillon wrote:

> Nice one!  I'm going to be using this all over the place myself.

I am missing something here.  Is there a practical use for this? :)

Jamie


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

Re: telnet to AF_UNIX sockets [PATCH]

[Matt Dillon]

:
:Looking at the patch, is it safe to assume that if there's a '/' in a
:hostname, it MUST be a AF_UNIX socket? If so, wouldn't a strchr(hostp,
:'/') be better than 'hostp[0] == '/''? This way one can use relative paths
:as well, not just absolute ones.
:
:--
:[ Joseph Mallett<[EMAIL PROTECTED]> ] [ http://srcsys.org ]

'maybe'.  Generaly speaking, to ensure that we do not break
some existing use of telnet it is best to be conservative.  You
can always do 'telnet -u relative_path'

-Matt


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

Re: telnet to AF_UNIX sockets [PATCH]

[Matt Dillon]

:
:On Wed, 23 May 2001, Matt Dillon wrote:
:
:> Nice one!  I'm going to be using this all over the place myself.
:
:I am missing something here.  Is there a practical use for this? :)
:
:Jamie

Many programs these days use unix-domain sockets as a rendezvous
for IPC between processes.  Being able to connect to such sockets
for monitoring, debugging, development, etc...  can be very useful.

-Matt

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

Re: Seeking recommendations for backup system

[Olivier Nicole]

Hi Steinar,

>I'm sure we could roll our based on freely available tools (eg. Amanda)
>- but by now I'm used to Tivoli ADSM/TSM, and *like* the convenience
>ADSM/TSM offers.  We need the ability to make backups (via Fast Ethernet)
>primarily of FreeBSD servers, but also Solaris, Linux and HP-UX. Easy
>restore is important.

Amanda works well, tho I did not had to check on restore yet :) I
think the restore works a bit like retore(8) does. You select the
files you want from a list then extract, and it will prompt you for
the tapes (or get them from your tape charger).

One good point, the user list is *active*, developpers do answer
questions, even stupid questions that could be solved by RTFM (I did
ask such question :)

I had it compiled on FreeBSD (various flavors), Solaris (old,
including SunOS 4.1). I heard there is issue with older Linux kernel.

>used with a decent sized tape library, probably LTO based, and FreeBSD
>4.3-STABLE.

Dunno what LTO is, my Amanda server is FBSD 4.3

According to a friend, best commercial would be by Veritas, tho their
FreeBSD client is old (3.3).

Best regards,

Olivier

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

Re: technical comparison

[Rik van Riel]

On Wed, 23 May 2001, Andresen,Jason R. wrote:
> On Wed, 23 May 2001, Kris Kennaway wrote:

> > That's all well and good, but I thought the aim here was to compare
> > Linux and FreeBSD performance on as level playing field as possible?
> > You're not measuring FS performance, you're measuring FS performance
> > plus cache performance, so your numbers so far tell you nothing
> > concrete.

*nod*

> Yes, they tell us that FreeBSD with softupdates and no write
> cache performs better in large cases than Linux with ext2fs and
> write caching enabled.
>
> Also my FreeBSD 4.0 boxes don't have the hw.ata.wc knob, so it's harder
> for me to test this.  Also, I don't know how ones goes about disabling the
> write cache in Linux without recompiling the kernel (which we have some
> custom mods in place, so I'm reluctant to do this).

1. I don't think I've ever seen a Linux distro which has write
   caching enabled by default. Hell, DMA33 isn't even enabled
   by default ;)

2. hdparm -W0 /dev/ to turn write caching off, -W1 to
   turn it on

3. I've seen many disks which got _slower_ with write caching
   turned on. Sure, it helps for sequential IO, but with more
   random IO the write caching on the disk can interfere really
   badly with the IO scheduling in the OS ... I've seen as much
   as a 5x drop in random IO performance with write caching ON
   compared to OFF.

I guess it would be good to follow Kris' suggestions and try
to do the tests on a level playing field.  The results might
just be interesting ;)

regards,

Rik
--
Linux MM bugzilla: http://linux-mm.org/bugzilla.shtml

Virtual memory is like a game you can't win;
However, without VM there's truly nothing to lose...

http://www.surriel.com/
http://www.conectiva.com/   http://distro.conectiva.com/


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

softc with resource sharing

[j mckitrick]

Any devices using the ppbus will end up sharing the hardware port.  If i want
to access this resource info, should i store it in my local driver's softc
structure, or extract it from the parent device (ppbus)?

jcm
-- 
"I drank WHAT ?!" - Socrates

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

Re: Device driver questions

[Sergey Babkin]

SJ wrote:
> 
> 2. Whats the use of device_ops structure and what does
>"ops" stand for?

"ops" definitely stands for "operations". I can't say off the top
of my head what this structure is but most probably a collection
of pointers to the functions of a particular driver which implement 
the device driver API.

-SB

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

Re: telnet to AF_UNIX sockets [PATCH]

[Jacques A. Vidrine]

On Wed, May 23, 2001 at 08:10:20PM -0400, James Howard wrote:
> I am missing something here.  Is there a practical use for this? :)

You are not the  only one.  I can appreciate the  `neat' factor, but I
cringed  at the  commit.  It  seems like  functionality that  would be
better put in a separate utility  (or port even).  It's not like you'd
ever want to run the NVT protocol over an AF_UNIX socket.
-- 
Jacques Vidrine / [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED]

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

Re: technical comparison

[Shannon]

On Wed, May 23, 2001 at 10:54:40PM -0300, Rik van Riel wrote:

> 1. I don't think I've ever seen a Linux distro which has write
>caching enabled by default. Hell, DMA33 isn't even enabled
>by default ;)

You are talking about controlling the IDE drive cache.

The issue here is write cache in the filesystem code.

-- 
[EMAIL PROTECTED]  _
__/ armchairrocketscientistgraffitiexenstentialist
 "And in billows of might swell the Saxons before her,-- Unite, oh
 unite!  Or the billows burst o'er her!" -- Downfall of the Gael

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

general speed differences between 4.1.1-RELEASE and 4.3-RELEASE

[Ed Hudson]

howdy.

maybe this has been discussed in 'hackers' or elsewhere,
before - i can't find a reference via the search interface.

i'm a long time freebsd user, and i've been struck by how much my
systems (3 of them)  have slowed down in its disk performance with
4.3-RELEASE, relative to 4.2-RELEASE and 4.1.1-RELEASE.

here is my data:

4.1.1-RELEASE,  ASUS A7A mbd, wd600-b
(60gig udma100 drive).
time to newfs an 8192mby partition
('a' partition in the first slice): 8seconds.

4.3-RELEASE, same mbd/drive:
time to newfs the same 8192 mby
partition: 36seconds

this is 4.5x slowdown!


this 'newfs' is done by an express install in both
cases.  even lowly linux-7.1 thinks this disk and system
are fast, and they zip along in comparison to 4.3-RELEASE.

i believe that a 4.2-RELEASE system would have the same
performance as the 4.1.1-RELEASE, based on my system
at work.

thoughts ?

  -elh


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

Re: general speed differences between 4.1.1-RELEASE and 4.3-RELEASE

[Mike Silbersack]

On Wed, 23 May 2001, Ed Hudson wrote:

>
> howdy.
>
> maybe this has been discussed in 'hackers' or elsewhere,
> before - i can't find a reference via the search interface.
>
> i'm a long time freebsd user, and i've been struck by how much my
> systems (3 of them)  have slowed down in its disk performance with
> 4.3-RELEASE, relative to 4.2-RELEASE and 4.1.1-RELEASE.

Write caching is now off by default.  man ata to see how to turn it back
on.



Seeing messages like this is becoming quite common on the lists since the
change was made.  On the other hand, I don't recall seeing any message
about disks being trashed when caching was enabled by default.  Given that
the option is tunable, perhaps it would be best to leave it enabled by
default.  Those concerned about power failures would still be able to
disable it if they wish.

With the extreme levels of annoying shown by those since the change, I
have the bad feeling that FreeBSD will get a reputation as being slower
than other OSes unless the default is returned to its previous state.



Mike "Silby" Silbersack



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

Re: general speed differences between 4.1.1-RELEASE and 4.3-RELEASE

[Ed Hudson]

Mike Silbersack <[EMAIL PROTECTED]> writes:
> Write caching is now off by default.  man ata to see how to turn it back
> on.

Mr. Silbersack, thank you very much.  you've restored my
systems to their pre-4.3 stunningly fast behavior.

to the hackers group, i apologize for polluting the air waves with
my original plea for help.

> 
> 
> Seeing messages like this is becoming quite common on the lists since the
> change was made.  On the other hand, I don't recall seeing any message

for my money, hw.ata.wc=1 soft updates OFF is a better performing
choice than hw.ata.wc=0 and soft updates ON.
(soft updates are great, but i really dislike the performance
stalls that it (or async mode) engenders with big copies/etc
for other processes).

if the freebsd group still chooses to keep hw.ata.wc=0 as
the default, i would urge perhaps a different mode for base
system installs.  the reason i used '8192m' partition in
my original mail was because the wait for a 60gig newfs was
pretty painful.


in my original message i made a reference to linux.
i'm a die-hard freebsd fan, but for work reasons etc i take
a look at linux from time to time.  in the same system that
i mentioned originally, i've tried the experiment of powering
off a machine (with no halt) after the first reboot after
a virgin suse-7.1 install.  linux couldn't put itself back together
without manual intervention - the fsck seemed to just freak.

even with the historic hw.ata.wc=1 effective mode of freebsd-*,
i've never seen such bad behavior as i had with the linux-7.1
system.


THANKS again to all you folks for the outstanding performance
and reliability that freebsd attains.

-elh



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

Re: Seeking recommendations for backup system

[Wilko Bulte]

On Thu, May 24, 2001 at 08:28:49AM +0700, Olivier Nicole wrote:

> >used with a decent sized tape library, probably LTO based, and FreeBSD
> >4.3-STABLE.
> 
> Dunno what LTO is, my Amanda server is FBSD 4.3

Linear Tape Open. Some industry-standard-to-be that wants to replace DLT.

-- 
|   / o / /  _   Arnhem, The Netherlandsemail: [EMAIL PROTECTED]
|/|/ / / /( (_) BultePowered by FreeBSD/alpha   http://www.freebsd.org  

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