Date: Tue, 15 Dec 2009 12:24:46 -0800 From: Jeremy Chadwick <freebsd@jdc.parodius.com> To: freebsd-stable@freebsd.org Subject: Re: Trouble with drive size detection - 31MB visible size on 1TB drive. Message-ID: <20091215202446.GA75896@icarus.home.lan> In-Reply-To: <3979a4b0912151044i5c3031ebo41ed0cb482461ea9@mail.gmail.com> References: <1260638581.00193503.1260625202@10.7.7.3> <4B23DC8B.8020807@FreeBSD.org> <3979a4b0912151044i5c3031ebo41ed0cb482461ea9@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Dec 15, 2009 at 09:44:22PM +0300, KOT MATPOCKuH wrote: > 2009/12/12 Alexander Motin <mav@freebsd.org>: > > To unlock drive permanently SET MAX ADDRESS ATA command should be used > > (probably the same as Linux uses) with Volatile bit set, to make it not > > restore on power cycle. I don't know how to send this command with > > legacy ata(4), you need some external tool. > Who knows this some external tool? :) > As I know hdparm is not ported to *BSD. > > > With new CAM-based ATA > > probably it can be send via `camcontrol cmd ...`. > On this machine I'm using FreeBSD 7.x and have no ahci(4) support :( > > I solved the problem by running "hdparm -N p1953525168 sdf" from linux > livecd, but this is not the fbsd way... Hmm... interesting. A couple nights ago I ended up writing some userland code that expands atacontrol(8) to support display of some SMART statistics (e.g. "atacontrol smart ad10")[1]. So what's this got to do with the above? ata(4) layer offers an ioctl (IOCATAREQUEST) which literally allows you to shove raw ATA commands at the disk itself. This means implementing the equivalent, i.e. "atacontrol cmd", is possible. Though like with camcontrol, the implications are risky. If folks are interested, I could try working on such, though honestly the argv[] parser in atacontrol(8) needs to be re-written (IMHO). What I'm saying: folks using straight ata(4) or ataahci(4) would use "atacontrol cmd" while folks using ahci(4) would use "camcontrol cmd". Please let me/list know if either of these things are of interest. [1]: It's hardly done and needs a *lot* of work, but I'll eventually get it into a state where it could be committed and people could hack on it/improve it. It's no where near as defined as smartmontools (re: disk vendor/model one-offs for attribute parsing and so on), but I figured FreeBSD users might want something out-of-the-box which might give them stats which are most commonly focused on (sector reallocation, drive temperature, high spin-up times, CRC errors, etc.). I guess you could say I'm a bit proud of myself given that I was able to figure out how to accomplish it by looking at some smartmontools source (messy, let me tell you...) and ata(4) bits (since the ioctls aren't documented). [2]: Yes, I'm still working on writing that doc that explains how to read SMART data. Going to have to end up doing it for work as well... oh the joys. :-) -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB |
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20091215202446.GA75896>