Common Gateway Interface (CGI) Monitor

A Common Gateway Interface (CGI) is a standard that facilitates communication between web servers and external databases or information sources. It acts as middleware, allowing web servers to interact with applications that process data and send back responses. The CGI standard was defined by the World Wide Web Consortium (W3C) and specifies how a program interacts with a Hyper Text Transfer Protocol (https://www.geeksforgeeks.org/understanding-http-using-browsers/) server.

SaunaFS has its own monitoring CGI-based server for cheking some of main statistics from a given cluster of our filesystem.

How to run it

After complete installation of SaunaFS filesystem, there should be available a binary denoted as saunafs-cgiserver which is the one related to our monitor system.

For starting this server, it would be enough to run command:

$ saunafs-cgiserver

As result of this command, the CGI will start as an asynchronous HTTP server running on port 9425 by default and on localhost.

Then, for accessing this tool, you can go to any local browser of you preference and access http://localhost:9425/sfs.cgi

Last show the result of what should be shown when CGI Monitor is running.

Q&A Section

1. What is reserved space?

   The reserved space of our filesystem is part of the Filesystem Metadata managed by the master. This variable refers to leght (the size of data space) of all files in our system that are marked as kReserved (reserved files).

2. What are reserved files?

   The reserved files are an special kind of file managed by our filesystem and are marked as File system nodes of type kReserved. There are other filesystem nodes like ordinary files, folders, symlinks etc...

   During the use of our filesystem, some ordinary files could be created. All files in our system have a reference to a sessionId, which is an identifier for a communication session with a client referring to it with its corresponding master servers.

3. When reserved files are created?

   At some point of using our filesystem, it could be possible that we try to delete a file. In this case, functions like PURGE and UNLINK are called in order to successfully complete file deletion. During those functions execution, it is checked at some point if the file to be unlinked and/or purged still has an active sessionid, which is some way to express that current file to be deleted is currently being used. When this happen, this ordinary file is marked as a kReserved filesystem node, which is a way to express it has to be a reserved file. It is important to note that, besides the condition of an active session for setting a file as a kReserved during PURGE operation, it is also necessary that it was selected to trash before.

   Reserved files are, in conclusion, files that our filesystem keeps tracks on when they are still being used or implied on a communication process between master and client. Because of this, our filesystem does not complete deletion process and keeps this data until it could be release by another process using it during a session.

4. When reserved files become not reserved?

   This happen when a PURGED operation is performed and a file to be purged is a kReserved file already. Ordinary files first are added to trash, then if they have an active session using it, the system marks it as reserved. Finally, when the purge operation is executed and this file was a reserved file before, then it should be completely deleted from system and not be reserved anymore.