On January 7, 2004 07:51 am, Charles A Edwards wrote: > On Wed, 7 Jan 2004 10:04:26 -0500 > > JoeHill <[EMAIL PROTECTED]> wrote: > > Unless I am minsunderstanding you, and fsck is used *in the recovery > > of the journal*? > > True for ext3, it is and should never be used for ReisferFS or XFS > > > I am also assuming that the 'file system integrity check' offered > > during the boot process is the same thing as 'fsck'. > > No. > Fsck would be invoked If anomalies were found during the 'file system > integrity check' > > Disk transactions are written sequentially to an area of disk called > journal or log before being written to their final locations within the > filesystem. Implementations vary in terms of what data is written to the > log. Some implementations write only the filesystem metadata, while > others record all writes to the journal. > > Now, if a crash happens before the journal entry is committed, then the > original data is still on the disk and you lost only your new changes. > If the crash happens during the actual disk update (i.e. after the > journal entry was committed), the journal entry shows what was supposed > to have happened. So when the system reboots, it can simply replay the > journal entries and complete the update that was interrupted. > > In either case, you have valid data and not a trashed partition. And > since the recovery time associated with this log-based approach is much > shorter, the system is on line in few seconds. > > Hardware and software errors that corrupt random blocks in the > filesystem are not generally recoverable with the transaction log and > necessitate the usage of fsck. > > After a crash or hard reset is when these hardware and software errors > are most likely to manifest themselves. > Choosing to skip fsck will allow these errors to not only remain but > also allow them to propagate and fester. > This may appear to have no effect on system performance or behaviour > but as time progresses, depending upon the root cause of the error, the > system behaviour may and can become erratic leading to even > non-recoverability and a forced reinstall. > > > > Charles
So I am still unsure what is best to do. Should I say yes to the check offered in the boot process after an improper shutdown (hang)? This can mean many attempts at recovery before I get back to a running system. I usually give up after 10~12 consecutive 'hangings'. And more to the point is this a known problem with my hardware configuration (see original 'hanging box' post) or am I faced with faulty hardware and how do I tell? I thought the ASUS A7N8X APIC hanging issue was addressed in the 2.4.22-21 kernel update. -- Paul O'Rorke [EMAIL PROTECTED] (school) [EMAIL PROTECTED] (legacy/home) [EMAIL PROTECTED] (for MSN messenger) [EMAIL PROTECTED] (for Yahoo messenger)
Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com
