One of the most critical threats to the reliability and robustness for file system is harboring bug (silent data corruption). In this research we focus on checksum mismatch since it occurs not only in the user data but also in file system. Our proposed solution has the ability to check this bug in file system of Linux. In our proposed solution there is no need to invoke or revoke checker utility, it comes as the integrated part of file system and has the ability to check upcoming updates before harboring bug make unrecoverable changes that leads significant data loses. Demonstration testing shows satisfactory results in file server and web server environments in terms of less memory consumption and avoidable delay in system’s updating.
File system is the major part of computer system which must be robust, reliable and intelligent enough that can handle faults and bugs. However, issues and problems still occur and machine can be crashed due unavailability of robust solution. Just like hardware failures, software bugs such as harboring bug in the system. The UNIX system has usually effected to split all obtainable resources to the most degree likely. Therefore, a single user in all users can assign all the accessible space in the file system. In many environments this is unacceptable because if admin assigned whole file system to one user, what about other users? As a result, a share mechanism has been added for limiting the amount of file system resources that a user can acquire [
Collision-resistant cryptographic hashes for meta-data have the ability to defend the journaling of file system by making it secure and increase the reliability and integrity of security in journaling file system [
The long structured memory policy has two types of benefits that can increase the speed and clean the memory from garbage that is responsible to make latency in file read and written in primary memory. It also increases the speed of the bandwidth of memory up to 6×. It has the ability to reduce the cost of memory by its normal operations that has the ability to run concurrently with other operations [
The fault tolerance and rapid fault discovery for both hardware and software is key structure blocks for building always accessible applications. But many structured software is not enough in their own to achieve the task of removing bug and corruption that leads towards crash in system. Likewise, built-in error revival is significant for handling the rising rate of fleeting hardware and software errors. But for designers of highly accessible systems having challenges those lies in addressing the problem such as the environment, cyber-attacks and silent data corruption [
In memory the phase change is also very big issue. Some scientist compared different types of storage to observe the performance that include the latency, input and output of disk and the performance of cache memory [
EXPLODE can comprehensively test storage systems by acclimatizing key designs from model scrutiny in a way that keeps their authority but removes their intrusiveness. Its crossing point lets programmer and designers rapidly program storage managers and also with normally compile them from existing modules. These system checkers can be executed on live and online system that represents not to imitate moreover, the environment also pieces of the system [
Most of the operating system has the ability to fight with any harmful behavior from device and from program. Some scientists investigate the inter-ope- rating system problem, which can increase in terms of amplified cost with the input and output virtual addresses allocator, which regularly encourages linear involvedness [
Based on our pervious literature review we noticed that the ext3 files system has poor performance due to its same allocation phenomena for both indirect block and data block by using tree structure in system. So through these strategies fsck faces more difficult to find harboring bug in system. Esext3 file system is based on Ext3 file system. This architecture contains a number of changes to improve not only speed also improves the memory consumption in file system. In proposed architecture the checker is integrated part of the file system so there is no need to invoke or revoke the checker. It works automatically when updates are ready to install in any field of the file system. Our proposed checker has the capable to report the presence of harboring bug in upcoming update in file system. Moreover, it uses XOR operation for checking harboring bug as we know that XOR is one of the most accurate and reliable operation among all operations those are used to check checksum mismatch.
Thanks to our proposed architecture of Esext3 file system which has the ability to works on TDMA (time division multiple access) that has the ability not only prevent harboring bug in file system also capable to do multitasking that is not available in Ext3 file system of Linux operating system. It also has the ability to stop upcoming updates and report harboring bug to the server and start updating system where it broke sequence when it receive harboring bug free update. This checker also has the ability to rollback and restores updates, if it found that server is not able to send correct and bug free update. We expect that Esext3 to meet the following criteria to reduce the memory consumption in the file system. While Ext3 which is limited roughly 5% of the main disk speed, we expect that the Esext3 can scan system with the greatest possibilities. As we saw in previous model that the performance dropped very quickly as the file sizes grow and the age of file also played an important role in delay scanning. We believe that this new file system checker can check on a constant speed. It will also allow administrator to decide when to execute the checker in the system. To repair file system on responsiveness cannot come together in productive environment. We focus to make sure that our file system can perform better than Ext3 file system.
The checker in file system scans the system in mean of ascending order (from 1st area to last area). First the checker check each group and their respective inode if found any unnecessary cross reference it will immediately discard it. Then it will read corresponding indirect region for self check if it found any cross reference metadata it will again discard it. These discarding of cross reference reduce the possibility of unwanted rescan of indirect area of corresponding field. After these operations the checker will authenticate the number of blocks including their size and check harboring bug by using XOR checksum in each layer of upcoming updates.
In this section, we describe the design and implementation of Esext3 file system. Esext3 stands for Extended Secure Ext3. It is the new secure version of Ext3 as shown in
nism that allows it to divide time in different updates. It uses intelligent TDMA for example if it gives 5 micro seconds to one update and update need 3 micro seconds, it will give only 3 micro seconds to it and go forward. It will not create its own backups and roll back system; it will use the traditional mechanism of restore point of OS. So we can save memory and time.
Suppose, system needs to update Data Bitmap, in our new system of Esext3 the system cannot update the field. System has to send data to checker and first checker scans that files and forward towards data bitmap for updating. If the checker found any harboring bug in system, it will stop and send back only that area of file that contain the bug and start entertaining other update if available. Thanks to its mechanism works on TDMA (Time Division Multiple Access) that can save time. In the meantime if system sends back the correct file it will start updating data bit map from same place where it found bug. It will use the restore system of OS so it can also help to reduce memory and time consumption.
In
Segment | Scan and read-through job |
---|---|
1 | Scan all fields of the Esext3 files system if found duplicate clime then rescan system and define the ownership of the file need to be updated |
2 | Separately check each directory for harboring bug before update the filed |
3 | Check the harboring bug in intercommunication between all directories |
4 | Check meta-data reference area if found harboring bug remove it and restore original file |
5 | Update file and field if necessary |
scans all fields in the file system if it found any duplicate clam then it will rescan the entire field in system. In the second segment if it found harboring bug in a single directory it scans each directory separately before the updating any field. In the third segment if the directories are interlinking with each other and having intercommunication and these files and directories also need updates so before update checker scans these files and directories. In the fourth segment checker also check the meta-data reference area for harboring bug if found it will remove it and restore original files and directories. In the last fifth segment the system will update all the necessary filed in the system and close all files and directories to reduce the chance of corruption.
In
are eight phases of checker in total. In first phase the checker will collect the data which need to be scan. In second phase checker will enable system data sending and checker to receive the required data that is “$”. In third phase the system will check the availability of data and make sure that the same date received that need to be update in system. In forth phase system applies the manual XOR operation of checksum to validate the checksum mismatch and validate the status of update. In fifth phase the checker validates that presence of bug if bug not found the checker will send it to next sixth of to extract information including time, data size and processing period. After that phase data will move to phase seventh that is the phase where system update finally started. In case if bug found in fifth phase it will report it to sender by making data’s invalid flag from 0 to 1, this phase extract uncertain condition that leaded checksum mismatch and create the report for sending to server about system harboring bug.
Step-1: Let S [System]: = 1 [Initialize]
Step-2: Let C [Checker]: = 1 [Initialize]
Step-3: Let Field [F]: = 1 [F Initialize]
Step-4: Connect S to F
Step-5: Detect whether update required
Step-6: If update needed go to step 7 else go to Step 11
Step-7: Send data toward C for harboring bug checking
Step-8: Check data if harboring bug found send acknowledgment to S for resending data to S and go to step 7 else go to Step 11
Step-9: If data has no error updates F and go to Step 6
Step-10: If any other filed need to be update go to step 4 else go to Step 11
Step-11: Exit
In
We conducted demonstration testing of our proposed solution on three main platforms 1) file server environment, 2) web server environment and 3) database server environment to insure its working capabilities and analyze the performance of it. More details of figures are cited blow so that we can observe all in deeply and understand the mechanism of our proposed solution. Furthermore, in conclusion we can understand the future work of our proposed Esext3 file system. In all three experiments of file server, web server and database server we used two variables first is I/O operation and other is offset operations. I/O operations are responsible for system updates getting data from server and (known as read) and update the required field if update is free from harboring bug. The offset operations are responsible for making connection between server and the client that need the update in the system.
We performed all the experiments on 2.1GHz Intel core i5 processor with DDR3 4GiB of RAM with Samsung SATA 500GiB of hard disk drive testing system with Linux kernel simulator 2.6.2 complete parameters are shown in
Parameter | Linux kernel simulator 2.6.2 | |
---|---|---|
No. CPUs Cores | 4 (2.1 GHz) | |
Memory | 4 GiB DDR3 | |
Disk Drive | 500 GiB | |
Disk Image Format | Think Flat VMDK | |
Files System | Ext3 | Esext3 |
I/O Scheduler | CFQ |
No. | Workload property | Ext3 | Esext3 |
---|---|---|---|
1 | File and Directory count | Single file per scan | Many files and Directories |
Directory tree deepness | Often deeply nested directories | Low and Homogeneous | |
File size | Incline towards many small files | Multi-gigabyte disk image files | |
2 | Meta-data operations | Lowest (40%) | Many (72%) |
3 | I/O synchronization | Asynchronous and synchronization | Asynchronous and synchronization |
4 | In-file randomness | Workload-dependent | Workload-dependent |
Cross-file randomness | Workload-dependent | Workload-dependent | |
5 | I/O size | Workload-dependent | Workload-dependent |
6 | Read-modify-write | Infrequent | Infrequent |
7 | Processing time | Workload-dependent | Increased because of manual XOR checksum |
As we know that our proposed solution is based on Ext3 so in third workload in table 3, I/O synchronization the Ext3 and our proposed solution Esext3 both Synchronization and Asynchronous to manage the I/O operations. In the fourth, fifth and sixth our proposed solution inherits the property of Ext3 file system. In the seventh property of
and write operation done by client for its upcoming updates. Whenever client observer that there is an update coming from server for the update of file system, the server first send hand shake request to client and that request is considered as read and when client perform some sort of operation on that hand shake and prepare the disk to manage update that is known as write. So, for ever update there is read and write operations to update system and checker perform check for harboring bug through our prescribed procedure explained in
In
In
In
In
Memory utilization is the key feature of any architecture that can make system more robust and reliable. Herein the memory does not mean the hard disk drive; it refers to the RAM the primary memory. And secondly we ignored the usage of virtual memory in our system because it has less speed and more time consuming memory. If we include it we should talk about paging so that it is purely different prospective of Linux file system. So that we are not involved in paging but most probably we will work on it near future.
In
web server and database server environments.) we can observer that system of our proposed architecture Esext3 file system uses less memory while updating in the environments of file server and web server, but in the case of database server not utilizing much memory due to repetitively disconnection form updating server. In
Our proposed architecture has some limitations as it come with new field of checker. This works on XOR operation to check checksum mismatch in file system so it consume more time as compared with traditional checker FSCK. It is using the traditional backup and rollback feature of ext3 so these features also responsible for making delay in updating the field in file system but this feature reduces the memory consumption as shown in
This architecture is good and suitable for the system which has zero tolerance for harboring bug. This Esext3 introduced new system that came with new filed known as checker having the responsibility to check system’s upcoming updates in any field of Esext3 files system. Our results showed that the system is not suitable for the machine or environment where time is more important as compared with reliability such as database environment. As we all know that “Security never comes for free”. It is the tradeoff between security and different type of costs just like time, memory, resources etc. This system has better performance where updates are offline as compared with online updates. Delay in updating filed can be potential drawback of our architecture while using network in the database server environment and it is an open issue. We are working on it and soon introduce new phenomena to overcome these delay in system.
Muhammad, R. and Riskhan, B. (2017) Esext3 for Reducing the Effect of Harboring Bug in File System. Journal of Software Engineering and Applications, 10, 354-369. https://doi.org/10.4236/jsea.2017.104021