Date: Wed, 07 Nov 2007 17:32:34 -0500 From: =?UTF-8?B?6Z+T5a625qiZIEJpbGwgSGFja2Vy?= <askbill@conducive.net> To: freebsd-current@freebsd.org Subject: Re: [ANNOUNCEMENT] Wiki for discussing P35/IHC9(R)/SATA issues set up Message-ID: <47323D02.2010208@conducive.net> In-Reply-To: <47322190.30504@deepcore.dk> References: <472F5846.1020304@gmail.com> <472F5D9A.9050900@delphij.net> <alpine.BSF.0.9999.0711051555550.45185@thor.farley.org> <20071106153509.GB91218@eos.sc1.parodius.com> <47308E19.70507@samsco.org> <47315094.6080405@yandex.ru> <47315158.5090304@gmail.com> <4731A755.7060701@yandex.ru> <4731AEE8.70606@gmail.com> <4731AFA5.9090104@gmail.com> <20071107160212.GA31717@eos.sc1.parodius.com> <4731FC4E.6040209@deepcore.dk> <alpine.BSF.0.9999.0711071415450.32427@thor.farley.org> <47322190.30504@deepcore.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
� wrote: *trimmed* > > On the ATAPI timeouts there not much to say, SATA ATAPI HW sucks jut as > much as ATAPI HW did it seems, It improved over time, simply because RMA's and complaint staff are too expensive for the razor-thin margins in the market. So, too will SATA ATAPI - but perhaps not before it simply disappears [1]. In any case, there isn't enough time or expertise to catch up with 100% of it. > the only way is to try and get it working > on as many as possible at the same time. That however means that someone > (usually me, you wont belive the ATAPI drive collection I've got here > already) needs to have all the drives available and time plus motivation > and needed skills to poke around to get it working. At least all the > controllers I have here in the lab and the two SATA ATAPI drives in same > work flawlessly... > > Sad but true. > > -S�ren >> Meanwhile - figuring a 2 year 'window' before the less-problematic chipsets & designs have garnered the greatest share of the market, it might be helpful if - much as has been done with controllers - a place was made where reported good and reported problematic SATA ATAPI drive hardware was listed. IOW - avoidance rather than fix. That needs several inputs: - what dmesg.boot reports, (discovered only after purchase) - what labeling is on the physical unit (not always available pre-purchase) - what product/brand was on the shrink-wrapped box (may help the *next* victim, anyway!) Keeping in mind that revisions aside, there is both multiple-branding of the same drives, and substitution of entirely different ones in the same packaging going on all the time, the mapping will change. (Aryeh - that might be a better use for your wiki.. a warning list..) Another reality that at least some of us have faced is that CD/DVD are slow, clumsy, power-hungry, oversize, of limited capacity, and not getting enough better (blue-ray et al) to matter. Ever again. It has long since become simpler and cheaper to equip ONE box or use a laptop to 'handle' CD/DVD for several other machines instead of assigning one per each. We haven't installed a new CD/DVD for several years, have *never* put one into a rackmount (arms are too short to reach Zurich from Hong Kong). It isn't hard to get by with one 'loose' PATA CD and one USB unit per ten machines, and one PATA DVD for 20 machines. Plus, of course, the one in an aged PowerBook that ends up doing 90% of the work, given it has a GigE and FW800 ports as well as USB2. And was integrated at the factory to JFW. So let's not waste too much time on CD/DVD's 'bad boys'. Just name 'em. NAND flash will finish what current USB memory - and iPod'ish thingies - started - changing the audio/visual/media market that underpins volume production of CD/DVD. 'Dead man walking' it is... and rotating memory in general not far behind... Bill [1] USB memory is already *way* cheaper than a CDR R/W drive here, and the larger capacity ones hold more than blue-ray or HD ever will. As to archival storage or backup - CD/DVD are too slow, (platter physics - not SATA) and too inefficient of space. On the basis of transfer speed alone, the only practical backup for a large HDD is -- another large HDD. Even then - RAID, a good resilient fs, and laziness have replaced routine backups for more folks than will publically admit it.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?47323D02.2010208>