Read Legacy IDE Device Details Safely from /proc/ide

On most current machines /proc/ide simply is not there any more, and knowing why saves you from chasing a phantom bug. This guide shows a read-only way to inspect the legacy IDE information Linux exposes, including channel and device paths, model, capacity and driver details, plus how to fall back to hdparm when the raw files are inconvenient. The examples match the local proc_ide(5) from Linux man-pages 6.7 and hdparm(8) 9.65.

Allow about ten minutes. You need a shell and, ideally, a machine that still exposes the legacy IDE interface. These checks read kernel-provided information only: nothing here repartitions a disk, changes a drive setting, or requires sudo.

1. Check whether the interface exists

/proc/ide is conditional. The manpage says it exists on systems with the IDE bus, so its absence is not by itself an error. Check it before writing a script that assumes the directory is there:

$ if [ -d /proc/ide ]; then
>     printf '%s\n' '/proc/ide is available'
> else
>     printf '%s\n' '/proc/ide is not available on this host'
> fi
/proc/ide is not available on this host

That second result is exactly what this machine returns, and it is the expected result on most modern hardware. It usually means the kernel is using a newer storage path, the legacy IDE driver is not present, or no IDE bus is exposed at all. Do not try to create /proc/ide yourself: procfs entries come from the kernel, never from an application directory.

2. Find the channel and device entries

When the directory does exist, list its files without changing anything:

$ find /proc/ide -maxdepth 3 -type f -print | sort
/proc/ide/ide0/hd0/model
/proc/ide/ide0/hd0/capacity
/proc/ide/ide0/hd0/settings
... host-specific entries ...

Exact names depend on the channels and attached devices. The documented layout gives a directory for each IDE channel and each attached device, with device files including cache, capacity, driver, geometry, identify, media, model, settings, smart_thresholds and smart_values.

Do not infer a disk's presence from a remembered path like /proc/ide/ide0/hd0. Use whatever find actually returns, because channel numbering and device names are host-specific.

3. Read the useful text fields

Read the human-friendly fields from one device directory. Replace IDE_DEVICE_DIR with a directory that showed up in the previous step:

IDE_DEVICE_DIR='/proc/ide/ide0/hd0'
for name in model media driver cache capacity geometry settings; do
    file="$IDE_DEVICE_DIR/$name"
    if [ -r "$file" ]; then
        printf '\n[%s]\n' "$file"
        cat "$file"
    fi
done

This skips a file that is missing or unreadable rather than stopping at the first gap. The values mean different things: capacity is a sector count, cache is a buffer size in kilobytes, geometry holds physical and logical geometry, and model identifies the manufacturer's model number. The driver and media entries describe the kernel's own view of the device.

Raw identification data is a different thing from these text fields. If you need to archive it, keep the output separate from prose logs and label it with the device path and collection time. Do not edit it, and never redirect data back into /proc/ide.

4. Inspect SMART-related values without changing them

The smart_thresholds and smart_values files expose IDE disk-management data in hexadecimal. Read them as raw data, not as a ready-made health verdict:

$ for name in smart_thresholds smart_values; do
>     file="/proc/ide/ide0/hd0/$name"
>     if [ -r "$file" ]; then
>         printf '[%s]\n' "$name"
>         cat "$file"
>     else
>         printf '%s is unavailable\n' "$name"
>     fi
> done
smart_thresholds is unavailable
smart_values is unavailable

Your output may show hexadecimal records or simply say a file is unavailable. The manpage only identifies these files as IDE management thresholds and values, and it defines no universal health score. For real disk-health assessment, use the storage stack and monitoring tool the device actually supports, rather than inventing a threshold from one field.

5. Use hdparm for a readable device view

The proc_ide(5) manpage itself recommends hdparm(8) for a friendlier presentation. Confirm the installed command and version first:

$ command -v hdparm
/usr/sbin/hdparm
$ dpkg-query -W -f='${Package} ${Version}\n' hdparm
hdparm 9.65+ds-1build1

For a device node you have already identified, ask for its stored identification information:

$ sudo hdparm -i /dev/DEVICE

/dev/DEVICE:
 Model=HOST-SPECIFIC-MODEL, FwRev=HOST-SPECIFIC-FIRMWARE, SerialNo=HOST-SPECIFIC-SERIAL
 ... host-specific fields ...

Replace /dev/DEVICE with the real block-device path. The -i option shows identification information held by the kernel, which can differ from information read directly off the drive with -I. The command may need elevated privileges to reach a device node, but sudo will never make a missing /proc/ide interface appear.

6. Handle the common failure modes

• Directory missing: treat /proc/ide as unavailable on this kernel and stop using paths beneath it. Do not manufacture entries or assume a SATA device uses the legacy IDE interface.
• File missing: reread the actual device directory from find. Optional or device-specific information is never guaranteed to exist.
• Permission denied: retry only the read that needs it, with the minimum privilege the host allows. Do not run a whole diagnostic shell as root out of habit.
• Unreadable or stale-looking values: record the kernel and tool versions, then compare with hdparm -i or a supported modern storage utility. Do not overwrite the procfs file or treat one field as a complete diagnosis.

There is nothing to undo in the /proc examples, since they only read transient kernel state. If you accidentally used an hdparm option that changed device state, stop, record the exact command and current output, and check the drive and distribution documentation before attempting a reversal. Do not guess the previous setting.