From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <5d7b27445236807043536410a584ee46@quanstro.net>
From: erik quanstrom <quanstro@quanstro.net>
Date: Sat, 28 Mar 2009 11:13:15 -0400
To: 9fans@9fans.net
In-Reply-To: <9795467bbf361247c67dd50a1d03ac4f@terzarima.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Subject: Re: [9fans] fossil caching venti errors
Topicbox-Message-UUID: cba45e90-ead4-11e9-9d60-3106f5b1d025

On Sat Mar 28 06:54:35 EDT 2009, forsyth@terzarima.net wrote:
> i've seen that just recently, but thought it might have been
> a failing (very old) drive, or a power failure beyond the endurance of the UPS.
> if neither of those are true in your case, it might be worth a deeper look.
> i also found there is a persistent problem that `check fix' won't fix.
> (since it's my principal file server at home, i can't easily investigate more
> until i can transfer the service to a new drive, leaving the old drive
> for experiment.)

i hope this is useful information, but i fear it might not be.

if the very old disk in question is a scsi disk, disk/smart in my
contrib area should be gentle enough to run on a live server
with any kernel.

if the very old disk in question is an ata disk, disk/smart requires
the sd changes in my contrib area to run raw ata commands
like smart return status.  it is also should be gentle enough to run
on a live server.

unfortunately, disk/smart is not smart enough to access ata
general purpose logging information (gpl), yet.  manufacturer
diagnostic tools are still helpful here but require booting into
dos.

by the way, i think there are a number of interesting gsoc projects
related to devsd and ata.  for example, a devsd device that adds
checksumming to another devsd device.  gpl support could be
done entirely outside the kernel.

- erik