NetBSD poor i/o performance?

JDCentral

Senior member
Jul 14, 2004
372
0
0
Does anybody know if NetBSD has slow/poor I/O drivers compared to linux?

I've started run NetBSD on two different computers (both old PIIs), and it always seems like most of the time the machine(s) are doing disk accesses - this was not an issue when running linux 2.6 (HD hardly ever moved).
 

Red and black

Member
Apr 14, 2005
152
0
0
I run NetBSD on all my machines, and don't see the behavior you describe. But I do know of at least two possibly related phenomena:

One difference between NetBSD and many default linux configurations is whether the filesystems are synchronous or async by default. NetBSD is sync by default, which means that every write call blocks until the data actually goes to the disk (though the disk may have internal caching that defeats this safety feature). Many default linux configurations have async filesystem mounts.

Also, I find that NetBSD's I/O *scheduler* is not so great, so that if one app is really hitting the disk hard, all apps suddenly have poor responsiveness.
 

n0cmonkey

Elite Member
Jun 10, 2001
42,936
1
0
Are you using NetBSD 2.x? If you're using 1.x you should update. Now. :)

Do you have softdep turned on? If not, turn it on. It'll speed things up.

I think Linux might be faster, but those two things should help.

EDIT: What chipset on the motherboard?
 

JDCentral

Senior member
Jul 14, 2004
372
0
0
Meh.. it was just a question - I had it on an old PII system. I'm now setting up an old Celeron system for use as a Router/firewall.

I'll try the async suggestion... I've decided that I love NetBSD much more than linux :)

EDIT: NetBSD 2.0.2
 

uOpt

Golden Member
Oct 19, 2004
1,628
0
0
What n0cmonkey and Red and black said, except that it is only metadata which is sync by default.

You need to turn on whatever NetBSD's solution to faster metadata is.

However, all these dependency graph solutions to fast metadata do take up more RAM, so on a very RAM-sarved machine it might still slow down.

In that case I would do a seperate /scratch filesystem (partition) which is mounted with asynchronous metadata where you do temporary stuff like unpacking tarfiles and compiling them.
 

TGS

Golden Member
May 3, 2005
1,849
0
0
I think there's been a thread like this before, concerning more disk utilization over more memory usage. It's not a bad thing that it's accessing the disk.

Also Disk I/O is not rated in disk activity or not. You'll want to run some performance metrix to validate if you are really getting a more restricted I/O on the same hardware.
 

n0cmonkey

Elite Member
Jun 10, 2001
42,936
1
0
Originally posted by: MartinCracauer
What n0cmonkey and Red and black said, except that it is only metadata which is sync by default.

You need to turn on whatever NetBSD's solution to faster metadata is.

However, all these dependency graph solutions to fast metadata do take up more RAM, so on a very RAM-sarved machine it might still slow down.

In that case I would do a seperate /scratch filesystem (partition) which is mounted with asynchronous metadata where you do temporary stuff like unpacking tarfiles and compiling them.

I'm pretty sure everything is sync, but I'm not positive. Turning on soft updates typically speeds things up quite a bit.

EDIT: Rereading the info, you might be right. Either way, softdeps re the answer. :p
 

Red and black

Member
Apr 14, 2005
152
0
0
Ah, I see from the mount man page that there are three modes: async, where the write returns immediately, default, where only the write returns as soon as the metadata goes to the disk, and sync, where the write returns only after the metadata and the actual data have gone to the disk.