NetBSD poor i/o performance?

[JDCentral]

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]

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]

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]

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

 

[n0cmonkey]

async is a bad idea. Post the output of mount, please. 🙂

 

[uOpt]

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]

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]

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

 

[Red and black]

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.