Implementation

TSS is currently implemented on the Linux-2.2.5 kernel. The following optimizations / improvements has been done on the basic TSS device driver.

• One of the performance bottlenecks of TSS is the latency due to the synchronous writes over the underlying devices. These writes can be made asynchronous and any failures in the asynchronous writes can be handled by using the existing data logging for the writes. With this modification to the TSS, the cleanup after the completion of asynchronous writes are carried out by a separate cleanup thread.

  These asynchronous writes soon ran into problems of deadlock. The possible reasons for this deadlock could be:

  - Too many asynchronous I/Os consume all available kernel memory and no kernel memory is available for SCSI cmd blocks, etc.
  - A large number of asynchronous requests may be generated, which the lower level SCSI device may not be able to handle.
  - A large increase in the request queue size, which the underlying SCSI device may not be able to handle.
  - Some mysterious bug in TSS code itself!

  A simple workaround for the problem has been to limit the number of asynchronous I/Os issued by the TSS device. A maximum of 8 asynchronous requests avoids this deadlock problem.

• The major delays in disk I/O are queuing delay, rotational delay and seek time. Two different optimizations have been investigated to reduce the seek time during the RAID1 I/Os. One approach places the two physical stripes of the single logical stripe, next to each other, if possible. This can be advantageous in case of full stripe writes, as a write has to go through both of the physical stripes. An alternative approach for RAID1 stripe placement is to put the two physical RAID1 stripes halfway apart in the disk. This can reduce the seek time, as during the reads only one of the physical stripes needs to be accessed. These optimizations have to be enabled separately with compile time parameters.

• The recent versions of the Linux kernels have fast parity calculation routines built-in. Linux-2.2.5 has an optimized assembly code for the parity calculations that has been used in the implementation of TSS device. Linux 2.2.12 or later kernels have optimized these routines further (using xmm registers), and could be used in future versions of TSS.

• During RAID1 reads, only one of the physical stripes will be accessed. The TSS device has an option to route the read requests to any of the two stripes to balance the load on the disks. A set of counters, one corresponding to each device, is maintained and is incremented every time a read is performed on that disk. This information is used during future read requests and read requests are balanced across the devices. This again has to be enabled with a compile time option.