RE: Regression observations & misc errata

Thanks for that, I will look into it. However, you might have missed my
point.

The couple of times I have had fatal filesystem inconsistencies have
been after a kernel panic, or ACPI induced ungraceful powerdown, and
even then it is so rare I cannot deliberately reproduce the problem.
Regardless of this, my point was not that the inconsistency occured, but
rather there has been a change in the resultant system behaviour
compared to pre 5.x releases. In the past the system would have failed
the fsck and dropped back into single user mode allowing for manual
intervention, now the system will boot normally and kernel panic the
moment the filesystem error is encountered.

The resolution is simple enough, but the cause of the panic may not be
immediately obvious, or may take several minutes to occur.

Seeya...Q

On Mon, 2003-05-12 at 13:34, 李鑫 Xin LI wrote:
> > -----Original Message-----
> > From: owner-freebsd-current_at_freebsd.org
> > [mailto:owner-freebsd-current_at_freebsd.org] On Behalf Of Q
> > Sent: Monday, May 12, 2003 9:57 AM
> > To: current_at_freebsd.org
> > Subject: Regression observations & misc errata
> > 
> > o Particularly bad "crashes" can leave the filesystem in such a state
> >   that continuing without a foreground fsck will cause a kernel panic
> >   when the effected files are accessed.
> >   I had a /var that exhibited this problem, only solution to panic was
> >   single user mode boot and 'fsck -y'  (no tracelog sorry)
> 
> I believe that this is some misunderstood. Foreground fsck is necessary when
> there is unexpected Soft Updates inconsistency, which can only arise on two
> situations:
> o Hardware error, for example, disk hard read/write error
> o Misconfiguration. This is common in 5-CURRENT and 4-STABLE boxes with ATA
> hard disk installed on the system.
> 
> What I will mainly willing to explain is the misconfiguration. By default,
> ATA write caching is enabled without ATA tagged queuing enabled. ATA tagged
> queuing is not enabled by default because only limited recent models of hard
> disk support this feature, and the ATA write cache, when not combined with
> tagged queuing, put the file system in a considerable danger of data loss,
> besides the significant performance improve.
> 
> Why ATA write cache will damage consistency? Because when having this
> feature enabled, the driver tend to report 'write is completed' right after
> it obtained data to be written and put it to the on board cache.
> Unfortunately, this behavior is not a good manner to the soft updates which
> requires driver to tell it the true situation whether the data is on
> reliable storage. On most SCSI hard disk drivers, however, because the
> tagged queuing capability, the soft updates code get the real situation
> about data, and there would be no problem with 'bad crashes'. Recently, IBM
> and some other manufactures have introduced tagged queuing into ATA devices,
> this would be a good news, and you might be glad if your hard driver is
> listed in ata(4) manpage indicating it has the feature, which is tunable in
> device.hints(5).
> 
> For one of my own testing FreeBSD boxes, which is a 5 years old Pentium-II
> with IDE hard drive which definitely doesn't support tagged queuing, I have
> disabled hw.ata.wc as soon as I have installed FreeBSD 5-CURRENT snapshot on
> it. This dramatically decreases the performance, but I got no problem in any
> crashes, except the ffs_blkfree panic caused by a small bug in recent vm
> change during update.
> 
> So I think you will find a way that, either accept the fact that with wc
> enabled, soft updates may panic across system crashes, or to accept the
> performance decrease. And if you have newer models of IBM hard disk, you
> will be lucky for you have the third choose.
> 
> Hope the information above helpful, and I will thank you in advance.
> 
> Cheers,
> delphij