Fsck − The unix† File System Check Program

Updates to the file system

Download 52.5 Kb.
View original pdf
Size52.5 Kb.
1   2   3   4   5   6   7   8   9   ...   49
2.5. Updates to the file system
Every working day hundreds of files are created, modified, and removed. Every time ale is modi-
fied, the operating system performs a series of file system updates. These updates, when written on disk,
yield a consistent file system. The file system stages all modifications of critical information modification can either be completed or cleanly backed out after a crash. Knowing the information that is first written to the file system, deterministic procedures can be developed to repair a corrupted file system. To understand this process, the order that the update requests were being honored must first be understood.
When a user program does an operation to change the file system, such as a write, the data to be written is copied into an internal in-core buffer in the kernel. Normally, the disk update is handled asynchronously the user process is allowed to proceed even though the data has not yet been written to the disk.
The data, along with the inode information reflecting the change, is eventually written out to disk. The real disk write may not happen until long after the write system call has returned. Thus at any given time, the
file system, as it resides on the disk, lags the state of the file system represented by the in-core information.
The disk information is updated tore ect the in-core information when the buffer is required for another use, when a sync(2) is done (at 30 second intervals) by /etc/update(8), or by manual operator intervention with the sync(8) command. If the system is halted without writing out the in-core information, the
file system on the disk will be in an inconsistent state.
If all updates are done asynchronously, several serious inconsistencies can arise. One inconsistency is that a block maybe claimed by two inodes. Such an inconsistency can occur when the system is halted

File System Check Program
before the pointer to the block in the old inode has been cleared in the copy of the old inode on the disk,
and after the pointer to the block in the new inode has been written out to the copy of the new inode on the disk. Here, there is no deterministic method for deciding which inode should really claim the block. A
similar problem can arise with a multiply claimed inode.
The problem with asynchronous inode updates can be avoided by doing all inode deallocations synchronously. Consequently, inodes and indirect blocks are written to the disk synchronously (i.e. the process blocks until the information is really written to disk) when they are being deallocated. Similarly inodes are kept consistent by synchronously deleting, adding, or changing directory entries.

Fsck − the unix file system check program
Table of contents
Can’t stat fcan’t make sense out of name
Impossible minfree=
Magic number wrong
Can not read blk
Partially truncated inode
Link count table overflow (continue)
Excessive bad blks
Bad state ddd to blkerr
Partially allocated inode i=
Root inode unallocated (allocate)
Cannot allocate root inode
I out of range i=
Zero length directory i=
Directory corrupted i=
Missing ‘.’ i=
Extra ‘.’ entry i=
Missing ‘..’ i=
Extra ‘..’ entry i=
Bad state s for root inode
No lost+found directory (create)
Sorry. cannot create lost+found directory
Sorry. no space in lost+found directory
Directory f length
Unref file i=
No space left in /lost+found (expand)
Link count type i=

Share with your friends:
1   2   3   4   5   6   7   8   9   ...   49

The database is protected by copyright ©userg.info 2017
send message

    Main page

Harley Davidson