Daniel Schneller's questions

The taccommand (catreversed) can be used to read a file backwards, just like cat reads it rom the beginning. I wonder, how efficient this is. Does it have to read the whole file from the beginning and then reverses some internal buffer when it reaches the end?

I was planning on using it for some frequently called monitoring script which needs to inspect the last n lines of a file that be several hundreds of megabytes in size. However, I don't want that to cause heavy I/O load or fill up cache space with otherwise useless information by reading through the file over and over again (about once per minute or so).

Can anyone shed some light on the efficiency of that command?

I need to find out about the impact different levels of disk I/O have on my application. To do so I am looking for a way to generate different amounts of disk load while I am running the application in a benchmark mode.

We currently get complaints from users about slow performance, however the information we get is very thin, so we cannot yet determine where exactly the problem is. I/O is the primary suspect, however we'd like to know for sure.

For starters I would be fine with something to create a configurable continuous read or write load, e. g. from /dev/zero to a tmp file or something. I know I can use dd, but this will push the disk to the limit immediately whereas I'd like some kind of throttle to make different test runs with increasing amounts of background traffic.

To make things a little more challenging, this has to run on RedHat9 boxes, which means kernel 2.4. So ideally this would be some kind of script that makes use of the default tools present anyway.

I would be interested in any experiences using CVS on a clustered file system with mulitple servers accessing it. I guess this is similar to what providers like SourceForge do.

Currently we use a RHEL based CVS server with an ext3 repository filesystem on a SAN.

The idea is to use several machines to handle CVS connections from clients all working on the same file system on a fast SAN. This redundancy could server for both load balancing and failover purposes (using e. g. a round-robin DNS that could be reconfigured if one of the servers were to fail).

SVN is not an alternative for various reasons, please do not start a CVS/SVN discussion.