cvs.openbsd.org needs an upgrade

Unfortunately, computer science being industrialized, has caused the move away from "computer scientists" and moved towards a split between programmers and computer engineers.

People who design Operating Systems, I would like to think know intimately about hardware, software and their efficient interaction.

Worse still, on an unrelated note, API's are removing the programming from programmers and bringing non-programmers to programming.

Yes, this punctuates everything you've said so far. You are looking at this from your limited point of view, while not realising that the picture is much larger and being taken care of by people who do understand the full situation. I am surprised that you have not been jumped on for this. I can only assume most people have stopped reading posts from you.

Manager: We need a version control system put in place for our devs.

IT admin: Okay, we will need fast access storage above all else for that.

Manager: Why?

IT admin: Version control systems tend to cause high I/O (lots of requests) because many files within the system tend to be requested at once, so as to put together any particular version to be given to a developer. Since developers don't always just ask for one file and since we have lots of developers, access time becomes the most important requirement.

Manager: What do you recommend?

IT admin: Disks with highest rotational speed for lowest latency, fastest head movement and top notch queuing and elevator sorting.

Manager: Elevator sorting?

IT admin: If a drive is requested to get a file from the start of the disk, then another from the end, another from the middle, another from the start and then lastly another from the middle again. Instead of the heads moving to the start, end, middle, start and then middle, elevator sorting allows the heads to go start, start, middle, middle, end. This dramatically reduces head movement and thus time to complete access for many pending files.

Manager: Oh, very interesting. So what are the best disks for this?

IT admin: At the moment, the drives with the fastest rotational speed, fastest heads and best queuing and sorting, are 15,000 rpm SCSI drives.

Manager: Oh don't we have scuzzy drives in our mail and database server?

IT admin: Yes, they are also areas that can be very high I/O hogs. SCSI is built for server use and tend to be more reliable also. The fact that the heads don't have to move as much probably also prolongs their life. Interestingly, this storage array could theoretically sustain extraordinarily high sequential transfer rates, but that will rarely, if ever, be needed by this system.

IT staff member: (just walked in, looking at notes on whiteboard) What!? That system alone can sustain over 600 megabytes per second! But you are only connecting it to a 1GHz P3 with just a single U320 controller in an ordinary PCI slot!?!? You see Mr. Thomas (Manager), what have I been telling you all this time? This guy should not be the admin of our infrastructure or trusted to spend any of our budget! The raw throughput this system could achieve, will be severely bottlenecked by the components used to connect to it! Blah blah blah, blah blah...

I think I was a bit to harsh in my reply to marco, sorry for that... but being an excellent software developer does not automatically make them an excellent systems administrator, integrator, or engineer, vice versa.

These guys, who develop a very well respected operating system, know how to spec storage for a core need of the development of that operating system.

I don't want to say that I'm better them him, I don't know him, but It feels like he has an agenda (high-end and costly SCSI system) that is not inline with what the project needs

YOU DON'T KNOW WHAT THE PROJECT NEEDS.

Your right, I don't fully know what the requirements are because I have nothing to do with the project.

So, what you mean to say, is that you are not qualified to decide what best meets the current NEEDS of this project? Then why do we continue to hear so much crap from you?

But from what I do know is the current server is a Pentium 3 with 1GB of RAM and is using 14 18GB Ultra160 SCSI drives in a RAID 5 configuration. Based on the specs I do have I could and will speculate that it is an off the shelf uni-proc P3 and that it has no PCI-X slots, only PCI, and that it's LAN connection is only 100MBit FDX. You can only go as fast as your slowest link and that is the LAN connection, the PCI bus, the memory bus (and how much you have), and lastly then CPU.

Nikolas. Ever thought that raw throughput is not what is needed here? How about access time? What if access time is above all else, the biggest performance killer? The developers know about bottlenecks. They find them in software and develop better ways to reduce them by changing algorithms, for just one example. Not all bottlenecks are clearly defined by product specifications. A 15,000 rpm SCSI hard drive is capable of transfering data at high rates and having very fast seek times due to the fact that when a head is moved into place, it does not have to wait long for the desired sector to come around and move under the R/W head. But maybe, just maybe, transfer rates are not what matters most in the needs of this cvs server. Maybe it is access time that matters most. And when the cvs server is at its busiest, pending commands can be much more efficiently serviced thanks to SCSI. The raw bandwidth that this system is capable of, might merely be an added detail that goes hand-in-hand with this low-latency system, yet never be needed. Who knows!? Me? You? Certainly the developers spec'ing this system know.

I don't fully know what happens in a CVS repo/server but I suspect that it is similar to ftp, http (no dynamic content), nfs, or smb file server and these servers are always network bound and when not networked bound, say for example 1GBit and 10GBit links, they are bound by the PCI bus.

cvs

A Concurrent Versions System server, is capable of allowing changes to files to be recorded in such a way that you could request any version of the file that the system has recorded. To do this with storage efficiency, instead of full files of each version being stored, this system can allow differences to be stored. So when you request a particular version of a file, the original file plus differences may be requested and then combined to present you that version of the file. This has the storage system requesting original files and other files that combine to make up any particular version. When the system is busy, you might find that access time is what matters, not raw brute force transfer rates.

cvs is far different from ftp.

A single 5400RPM IDE drive can saturate a 100MBit link and a 1GBit link can saturate the the PCI bus.

In networking bandwidth, packets per second tend to be more meaningful than bytes per second. You could fully consume a CPU with lots of small packets while getting nowhere near the saturation point of the network interface or system bus. Even though that CPU would normally hardly break a sweat with typical packet size transfers and be able to saturate some other bottleneck. Same goes for high disk I/O demanding applications. If your application causes lots of requests per second, causing head movement, your transfer rates go out the window and reliance is placed more on how quickly those heads can move, how quickly the disk spins (faster spinning disk does not just allow faster transfer rates, but also allows faster access to a sector by reducing the time it takes for that sector to appear under the heads) and how efficiently the system can organise what order those requests should be carried out, to reduce back-and-forth head movement.

The fact that this system might be able to sustain a sequential bandwidth far greater than the network interface and system buses can handle is beside the point. Because that bandwidth might not be desired or ever requested. The point is access times. To get fast access times, it just so happens that you buy a system which also happens to be capable of high sustained sequential bandwidth.

This has to do with SCSI's command queuing and low read/write times do to high RPM drives, 10,000+, with non-sequential / random access patterns SCSI will always beat IDE because IDE doesn't have ether of those features.

That seven times faster SCSI disk, was 7,200 rpm, just like the IDE disk. But yes, SCSI kicks arse for high I/O. A busy cvs server can be a high I/O demand application.

SATA is designed for anything you want it to be. It is only a bus interface, like SCSI, and what really matters, both in SATA and SCSI, is what's connected to it. With drives such as the SATA based WDC Raptor it can be a valid competitor against SCSI, at this point only Ultra160, because the SATA interface supports most of the features that make the SCSI interface the niche product it is today.

What a load of tripe. Every design has strong and weak points. Often when trying to strengthen one area, you end up weakening another. SATA is designed for desktop use, that is its main market. SCSI is designed for server and high end workstation use and that is where it is marketed. Did you notice at storagereview, the SCSI drive running a high I/O benchmark about 65% faster than the SATA 74GB Raptor? SATA may be getting used a lot now in server use, but I have almost always seen SCSI as an option in those same systems, for the higher end.

P.S umm I not sure which SATA drive your talking about... but I'm basing all of my comments off of the new WDC 74GB Raptor, not the 36GB Raptor or any other SATA drive.

Did you look at the storagereview links? I linked to the 74GB Raptor.

SCSI is not dead nor is it going to die anytime soon. It has it's niches, especially in the high-end and big iron markets.

When was the last time you touched "big iron"?

Those people obviously forgot to do random access pattern tests and again this has to do with the SCSI vs IDE bus. IDE will always loose when you compare this aspect.

High I/O, does not mean that the data flows at a high rate, it means that there are a high number of requests (often small). Lots of requests all over the disc cause... random accesses. cvs can be high I/O and I imagine OpenBSD's core cvs server can get pretty busy at certain times of the year.

But with SATA-I, SATA-II, and SATA-III standards you will see in the coming years that it will dominate the entry-level server market and will have a sizable market in mid-level servers. This is do to simple economics and the reasons stated above (and below), you can quote me on that.

I don't doubt that SATA will continue to get better, but so will SCSI. Most importantly though, is that OpenBSD's needs are immediate! Coming years? They need storage NOW!

One thing many seem to be forgetting is that it's the job of a good, one that has has a real I/O controller, cache, etc., RAID controller to play traffic cop to efficiently sort and move data to and from the disks. This lessens the need for command queuing and low access times on the drives if it is done correctly.

Cache is only good if it can be exploited. Cache can also INCREASE access times if the data is not found within the cache. Because the cache is first checked, then it is requested from the platters, placed into the cache and then given to the requesting application. Also, in these situations where cache is of little benefit, the larger the cache the worse the access time due to greater latency caused by searching through a larger cache.

If a drive does not do command queuing, then when the drive is busy it's bus is idle and when it's bus is busy the drive is idle. For an access time reliant server, do you want a disk system that has a duty cycle split between disk and bus that has at all times one of them idle? There is latency getting commands to go from the controller on the motherboard to the controller on the disk. This can be alleviated by having queuing on the drive. Thank God IDE finally has queuing coming with the latest SATA drives. After all these years!

? maybe it was in that link you gave me, sorry didn't read it (yet)... Ultra320/15K vs SATA-I/10K, no contest, SCSI will win all of the tests.

What is the fastest hard disk drive you can buy? Whether by fastest you are referring to transfer rates, access times or both? A 15k rpm SCSI drive. The OpenBSD project just wants what is best for their most important core server.

You can and it does but he stated that he wants to use it in a JBOD array configuration and that is just wrong.

Actually, I don't recall reading Marco state that he was going to use it in JBOD config. And notice that he also mentions the use of a donated RAID card? Why buy something more flash, with built-in RAID when he already has a good RAID card to go with plain SCSI storage?

No I haven't. SATA paired with the right drives can do just about anything Ultra160 can.

That's great. Now how about considering that they are going with U320 drives?

This problem is easy to overcome with other cheaper cost effective solutions, SCSI or not.

SCSI currently provides the best access times. It also provides the best transfer rates, but I don't think that is highest on their priority list. The use of SCSI-IDE bridges is a nasty hack for an important server, which would increase risk of failure.

One of those could be splitting the CVS trees onto separate servers.

Hang on. You have demonstrated and admitted that you know little about cvs and it's requirements, but now you are giving OpenBSD developers, developers by the way, who are currently developing a better OpenCVS system at the source code level, advice on setting a cvs server up?

My bullshit meter is ringing like crazy and thats why I'm "putting up a fight" with his request.

The problem is, that you don't know about cvs or OpenBSD project needs. So you're bullshit meter should be switched off. You should take your fight elsewhere. I think everyone else here is sick of hearing your ill thought out bullshit.

But I still stand by my earlier statement that I feel he has not throughly thought this through.

You are ignorant of the needs in this case. So how could you know whether this has been throughly thought through?