JPH03191421A - Computer system with disk device - Google Patents

Abstract

PURPOSE:To help the search of a cause for the abnormality of a disk device by providing the computer system with a means for storing the contents of a disk access request, the contents of a command and status information or e like from the disk device and editing and outputting the stored data. CONSTITUTION:When a disk access system call is generated from an application task 1, a system call interface routine 2 stores the sort and time of a system call request in a system call tracing area 12 and goes the execution of a normal system call service. After completing the service, the result and time are stored in the area 12. A request service routine 7 stores the time and the contents of a request, generates a command to a disk controller 9, stores the processing end time, and returns the stored contents. The contents of the stored request include a request function, a block number in a disk, reading/writing size, a reading/writing buffer pointer, etc.

Description

DETAILED DESCRIPTION OF THE INVENTION [Object of the Invention] (Industrial Application Field) The present invention relates to a computer system equipped with a disk device as a storage device.

(Prior Art) In recent years, computer systems have been widely used for monitoring and controlling industrial plants. Such computer systems constantly monitor the status of each device that makes up the plant or status variables such as temperature, pressure, and flow rate within the system, and perform control based on the monitoring results. etc.

In order to perform the above tasks, the application software prepares multiple program units (hereinafter referred to as ``tasks'') and processes them in real time by running them in parallel. For this purpose, a real-time multitasking operating system (hereinafter referred to as 'O8') is used.

As the plant size increases, the number of tasks increases, and the control between tasks becomes more complex, the O8 itself is required to be large-scale with various control functions, and the application programs are also large-scale. Nowadays, things with expandability and flexibility are being created.

In such systems, software including O8 is usually run on random access memory (hereinafter referred to as 'RAM') for reasons of scale, debugging efficiency, and scalability; Equipped with a disk device as a secondary storage device, programs can be downloaded from the disk device.
Load it into AM and run it. It takes the form of

Furthermore, in plant monitoring and control, reference and storage of various data is an essential function, and disk devices are utilized for this purpose as well.

Here, the process of accessing the disk device will be explained with reference to FIG.

When reading or writing files or data to a disk, first, application task 1 issues a system call. The system call is sent to the input/output system 4 (hereinafter referred to as 'IOS') in O33 via the system call interface routine 2.
required.

Upon receiving a system call, the l0S4 creates an area called a request/result block 5 in main memory, stores the request from the application in it, and then executes the request service routine in the disk driver 6. Call 7.

The disk driver 6 is software that serves as an interface between the l054 and the disk device 8, and is the part that actually controls the disk device 8.

The request/result block 5 passed to the request service routine 7 stores information such as how much data is to be read or written from which block on the disk.

When the request service routine issues a command to the disk controller 9 according to the request contents, the operation of the disk device starts, and the disk main body 1
A read or write to 0 is executed.

When the operation of the disk device is completed, a completion interrupt is generated at that point, and control is transferred to the interrupt processing routine 11 within the disk driver.

The interrupt processing routine 11 analyzes the cause of the interrupt.

By inputting status information from the disk controller 9, the quality of the operation result is determined, and after storing the result in the request/result block 5, it is transmitted to the IO 34.

10S4 determines whether the request from application task 1 has been completed, and if so, notifies application task 1 of the operation result information via system call interface routine 2. .

(Problem to be Solved by the Invention) As mentioned above, when performing disk access, a request system call is first issued from application task 1, but normally the content requested by the system call is is the file name and size on the disk, and whether it is read or written.

In order to actually read/write data on the disk, it is necessary to know where the specified file is stored on the disk and to tell the disk controller 9 its block number. The l054 has the role of disassembling requests from applications and generating requests that match the file structure within the disk.

In other words, even if an application makes a write request to a certain file, the actual disk operation may involve reading several times to find out the storage location of the file, or if there is a large amount of writing. The write operation may be divided into several times.

In such a situation, the following problems may arise.

If something goes wrong with the disk device, an error status will certainly be returned to the application task, but it is difficult to know where on the disk the defect actually occurred, or whether there is something wrong with reading or writing. ,
Failure analysis is difficult because the detailed status information from the disk controller is not known all at once.

In other words, conventionally, when performing these failure analyses,
It was necessary to know the memory contents and information from the IO boat only about the final state at the time of occurrence of the abnormality, and to check the operation by outputting disk commands according to the operation.

Also, from a performance analysis perspective, the time from issuing a system call to returning from an application can certainly be measured at the application level; No information is available about the overhead of driver routines.

In other words, the true load factor for application tasks cannot be determined.

In this way, performance and load can conventionally only be measured in a form that includes both application task 1 and the routines inside 053, and the program/code execution time of the driver routine is determined and corrected on paper. was.

Therefore, the present invention improves maintainability and evaluates and improves performance by visualizing information that helps investigate the cause of abnormal disk access and the actual movement of disk access. The purpose of the present invention is to provide a computer system equipped with a means for providing information that can be used.

[Configuration of the Invention (Means for Solving the Problem) The system of the present invention includes means for storing the type of request, access result, and time in response to a disk access request from an application program, and a means for controlling the disk. Contents of commands actually issued to the disk by the disk driver and status information from the disk device.

and a means for saving the time, and a means for editing and outputting the saved data, and provides information to assist in investigating the cause of abnormal disk access, and information to help investigate the cause of abnormal disk access.
This makes it possible to visualize the actual access movement to improve maintainability and evaluate and improve performance.

(Operation) In the system call interface routine,
By storing information in the system call trace area, it records when and what system calls were issued by an application task, how much time was spent executing the system calls, and what the execution results were.

Also, in the driver routine, by saving the request contents from IO5 and status information from the disk controller in the driver trace area,
It records which block on the disk is actually accessed, when and with what command, when the access is completed, and if an error occurs as a result, detailed information from the controller is recorded.

Furthermore, by activating the trace output utility, the trace information recorded above is edited, for example, in chronological order, and outputted in an easy-to-read format to a terminal device such as a console display, a printer device, or the like.

(Embodiment) FIG. 1 is a system configuration diagram showing an embodiment of the present invention. In the figure, the same reference numerals as in FIG. 6 indicate the same or corresponding parts.

As the application part, application task 1 and system call interface routine 2,
and a system call trace area 12.

Related elements within O3a include l054, disk
There is a driver 6 which includes a request service routine 7 and an interrupt handling routine 11. Furthermore, a request/result block 5 and a driver trace area 13 are included as data areas.

The above is the software configuration, and the hardware includes a disk unit N8, which is composed of a disk controller 9 and a disk main body 10.

Further, a trace output utility is provided to output the information held in the system call trace area 12° driver trace area 13 to the terminal device 14 or printer 15.

FIG. 2 is a flowchart showing the processing procedure of the system call interface routine.

When a disk access system call is issued from application task 1, system call interface routine 2 first determines the type and time of the system call request, as shown in the flowchart in Figure 2. Store in trace area 12 2
1) Move to normal system call service execution (
22). After the service is completed, the result and time are stored 23 in the system call trace area 12.

The above system call service is executed at 053. First, the l054 receives a request, changes the request content to match the file system on the actual disk, stores the content in the request/result block 5, and then processes the request in the disk driver 6. Call request service routine 7.

FIG. 3 is a flowchart showing the processing procedure of the disk driver.

In the request service routine 7, as shown in the flowchart of FIG. 3(a), one time is stored 31, the request contents are stored (32), a command is issued to the disk controller 9 (33), and the process ends. Store the time (3
4) Return. The stored request contents include the request function, block number on the disk, read/write size,
Contains information such as read/write buffer pointers.

When the disk controller 9 accesses the disk main body 10 and its execution is completed, the O33 is notified by an interrupt, and the interrupt processing routine 11 is activated.

As shown in the flowchart of FIG. 3(b), the interrupt processing routine 11 stores the time (35), reads the status from the disk controller (36), stores the result (37), and stores the end time (35). 38) and then
Return to 054.

l0S4 repeats the request call to the driver described above until all request contents disassembled from the system call from application task 1 are completed, and finally transfers control to application task 1 via system call interface routine 2. return.

FIG. 4 is a flowchart showing the processing procedure of the trace output utility 16.

The information stored in the system call trace area 12 and the driver trace area 13 is extracted from the system call trace area 12 and the driver trace area 13 by the trace output utility 16 as shown in the flowchart of FIG. Be a leader 4
1) Edit the data in chronological order to form a form 42) Select the output light 43) Output the editing results to the output light of a specified terminal device, printer, etc. (44) .

FIG. 5 is a diagram showing an example of trace output output to the printer device [15]. The output results edited by the trace output utility 16 are, as shown in FIG. Item 51 and request service routine 7 obtained from driver trace area 13 include information such as request content, time, block number on disk, read/write size, read/write buffer pointer, etc., and interrupt processing. It consists of driver routine items 52 representing information such as time and results based on the routine 11.

As described above, if any abnormality occurs regarding disk access, it is possible to know from the trace data what kind of error occurred when what block was actually accessed by what kind of command to the disk device. This increases the efficiency of troubleshooting.

In addition, since it is possible to accurately trace the execution time of system calls and the operating time of IO5, drivers, and disk devices, it is possible to analyze the true load rate of application tasks from this information. .

[Effects of the Invention] As explained above, according to the present invention, it is possible to obtain information that allows easy pursuit of the cause of an abnormality in a disk device that is essential and important for the operation of a plant monitoring computer system. As a result, maintainability can be improved and applications related to disk access can be
Effective data for performance evaluation, such as task load factor analysis, can be obtained, and based on this data, improvements can be made to improve the performance of application programs.

[Brief explanation of drawings]

FIG. 1 is a block configuration diagram of a computer system representing an embodiment of the present invention, FIG. 2 is a flowchart showing the processing procedure of a system call interface routine, and FIGS. 3(a) and (b) are disk diagrams.・A flowchart showing the processing procedure of the driver, FIG. 4 is a flowchart showing the processing procedure of the trace output utility, FIG. 5 is a diagram showing an example of trace output, and FIG. 6 is a block configuration diagram of a conventional computer system. . DESCRIPTION OF SYMBOLS 1... Application task, 2... System call interface routine, 3... Operating system, 4... Input/output system, 5...
Request result block, 6... Disk driver, 7...
・Request service routine, 8... Disk device, 9.
... Disk controller, 10... Disk body,
11... Interrupt processing routine, 12... System call trace area, 13... Driver trace area, 14... Terminal device, 15 Printer device, 16
...Trace output utility. (7317) Agent Patent Attorney Noriyuki Chika (8869) Agent Patent Attorney Ken Komaru Figure 2 Figure 1 Figure 3 Figure Figure

Claims (1)

[Claims] In a computer system equipped with a central processing unit that executes application programs using a real-time multitasking operating system as basic software, and a disk device that inputs and outputs data necessary for the execution of the application program, In response to a disk access request, a means to save the type of request, access result, and time, and a disk driver that controls the disk, the contents of the command actually issued to the disk, status information from the disk device, and What is claimed is: 1. A computer system equipped with a disk device, comprising means for storing time and means for editing and outputting the stored data.