Carlos, On Wednesday 16 March 2005 15:21, Carlos E. R. wrote:
The Tuesday 2005-03-15 at 08:52 -0800, Randall R Schulz wrote:
On Tuesday 15 March 2005 06:39, Damon Register wrote:
Darryl Gregorash wrote:
**Never** fsck a mounted partition.
Ok, I'll bite. Why not? Please don't think that I wish to argue, I just want to learn.
The kernel has much cached file system information in RAM. If fsck changes anything on the disk, then the data the kernel holds no longer matches that on the disk, yet the kernel does not "know" this and will access the device as if the information it holds accurately reflects the state, structure and contents of the drive. Bad consequences are very likely to ensue.
That's true. However, a theoretical point raises to my mind. O:-)
It should be possible for the kernel to know what is happening and update its internal buffers. In other words, the kernel could keep track of what fsck is doing, update or flush or empty buffers as appropriate, and conversely, be able to write to disk whatever the rest of the OS seems fit, and informing fsck of what has changed.
It should be possible, albeit very complex. And slow.
It is probably possible in principle, though probably not worth it in practice. There are two issues that I can think of: 1) Programs like fsck (more precisely, one of the file system-specific fscks) access disks in so-called "raw" mode, bypassing the kernel buffer pool. This makes them rather faster and they don't have to worry that their writes are deferred until the buffer cache must be flushed. 2) Much of the kernel's internal state that is derived from disk contents is interpreted. I.e., the disk contents are read and rather than being used directly are interpreted and used to build internal data structure. Even if the kernel took note of every write that fsck performed a write, it is not necessarily easy for it to reflect all those changes internally. For one thing, fsck may use several writes to effect what is a single logical change to the file system. But the kernel just sees a bunch of independent writes. You'd need a separate protocol by which fsck said something like <superbBlockUpdate> write() ... write() ... write() ... </superBlockUpdate> or <freeListRebuild> write() ... write() ... write() ... </superBlockUpdate>. Once you design the structures and protocols that permit this, you're probably going to just throw up your hands, declare it not worth the effort and declare: Thou shalt not repair mounted file systems. And here we are.
But I have seen more complex feats... like, on a double computer, updating half of a mirror disk with the computer continuing normal processing, then suddenly switching to the other, updated half, without interrupting service. Roughly so, but almost correct explanation.
-- Cheers, Carlos Robinson
Randall Schulz