Mailinglist Archive: opensuse (3666 mails)

< Previous Next >
Re: [SLE] PC Crash: Hard Disk Problems
  • From: "Carlos E. R." <robin1.listas@xxxxxxxxxx>
  • Date: Thu, 17 Mar 2005 21:50:36 +0100 (CET)
  • Message-id: <Pine.LNX.4.58.0503172147090.8221@xxxxxxxxxxxxxxxx>

The Wednesday 2005-03-16 at 18:42 -0800, Randall R Schulz wrote:

> It is probably possible in principle, though probably not worth it in
> practice.

Probably. It would make sense for high reliance 24*7 systems, perhaps.

> 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.

Correct.

> 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>.

Yes, fsck would have to work trough the kernel, not directly. Or design a
protocol, as you say.

> 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.

X'-)

--
Cheers,
Carlos Robinson


< Previous Next >