Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 23 May 2019 08:43:47 -0700
From:      Patrick Powell <papowell@astart.com>
To:        freebsd-scsi@freebsd.org
Subject:   Re: [Bug 202712] [cam] [ata] System doesn't recognize older hdd after boot
Message-ID:  <23f15e62-85e0-6196-fba1-adabfc3be416@astart.com>
In-Reply-To: <bug-202712-5313-N2QMhI5OLe@https.bugs.freebsd.org/bugzilla/>
References:  <bug-202712-5313@https.bugs.freebsd.org/bugzilla/> <bug-202712-5313-N2QMhI5OLe@https.bugs.freebsd.org/bugzilla/>

next in thread | previous in thread | raw e-mail | index | archive | help
I appreciate the desire for legacy support,  but re-adding (sp?) CHS 
support seems to be a bit silly.  I tossed the last CHS drives in 2018 
and they had not been powered up since 1999.

If you are REALLY desperate for data recovery,  then a Data Recovery 
outfit can do a sector by sector copy of the old CHS drive to a newer 
drive, or even a memory stick.  You do not even need to have a 
functioning drive.  Of course it may be a bit expensive...  but if you 
need the data, cost may be irrelevant.

On 2019-05-22 23:34, bugzilla-noreply@freebsd.org wrote:
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=202712
>
> Scott Long <scottl@FreeBSD.org> changed:
>
>             What    |Removed                     |Added
> ----------------------------------------------------------------------------
>                   CC|                            |scottl@FreeBSD.org
>
> --- Comment #39 from Scott Long <scottl@FreeBSD.org> ---
> The code in sys/cam/ata is generic protocol and transport support for all
> devices.  The code in sys/dev/ata is controller-specific drivers.  In simple
> terms, adding CHS support would happen in sys/cam/ata.
>
> I have mixed feelings on adding CHS support.  As others have mentioned, it's
> ancient, and it's nearly impossible for people to test.  It would exist as a
> poorly tested codepath that would be prone to accidental breakage.  The cost of
> keeping it working, in terms of equipment procurement and operation, would
> likely outweigh the benefit.
>
> It looks like Amazon has a PCIe add-in card for ATA/IDE, but I haven't owned a
> working ATA drive in almost 10 years, and I probably haven't owned a functional
> CHS-only drive in at least 20 years.   I have no idea where I'd get one, other
> than to buy batches of them off of Ebay and hope to find some that work.  20+
> years is a long time for a hard drive, even in the best of circumstances.
> Moisture will invade the platter cavity through the breather hole.  Lubrication
> will slowly evaporate off of spindle and armature joints and redeposit itself
> onto the platters and heads.  Capacitors on the circuit board will slowly leak,
> and copper and aluminum connectors and traces will corrode.  I'm impressed that
> you have a working 400MiB drive, that's a 25 year old drive at this point.  I'd
> worry that it would stop working in the near future.
>
> If I were to build a rig to operate a CHS-era IDE drive (or any ATA/IDE drive
> for that matter), it would be solely to recover and archive the drive data to
> modern storage.  For that, I'd use software that supported the use-case.  If
> that means using an older version of FreeBSD, or using Linux, I'd do that.
> It's such a niche use case that I'd spend considerably more time resurrecting
> and testing CHS code than I'd spend actually recovering the data, and that's
> just not an interesting use of my time.
>
> If there's community interest in supporting CHS long-term in FreeBSD, my
> recommendation is to create a IDE-CHS specific transport in CAM that lives
> alongside the ATA/SATA support, but does not rely on it.  This probably means
> copying sys/cam/ata/ata_xpt.c to sys/cam/ata/ide_xpt.c, removing the
> SATA-specific logic in it, and adding in the IDE and CHS specific logic.  Nice,
> clean, and isolated so that it's less likely to be accidentally broken, and
> people working on SATA aren't likely to trip on it.  This would probably be a
> week of work at most, assuming that test hardware is available.
>

-- 
Patrick Powell                 Astart Technologies
papowell@astart.com            1509 Hollow Ct.,
Network and System             San Diego, CA 92019
   Consulting                   Cell 858-518-7581 FAX 858-751-2435
Web: papowell at astart dot com




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?23f15e62-85e0-6196-fba1-adabfc3be416>