Trouble with drive size detection - 31MB visible size on 1TB drive.

Jeremy Chadwick freebsd at
Tue Dec 15 20:24:48 UTC 2009

On Tue, Dec 15, 2009 at 09:44:22PM +0300, KOT MATPOCKuH wrote:
> 2009/12/12 Alexander Motin <mav at>:
> > 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 at |
| Parodius Networking              |
| UNIX Systems Administrator                  Mountain View, CA, USA |
| Making life hard for others since 1977.              PGP: 4BD6C0CB |

More information about the freebsd-stable mailing list