Fix Linux device-mapper disk paths by dbwiddis · Pull Request #3299 · oshi/oshi

dbwiddis · 2026-05-24T21:38:48Z

Description

Gate LVM-specific device-mapper partition paths on nonblank LVM volume group/logical volume names
Handle CRYPT device-mapper disks separately as encrypted volumes using DM_NAME with a /dev/dm-N fallback
Extract common device-mapper classification/path helpers so the hardware-dependent branches have unit coverage
Add Linux-only tests for LVM/CRYPT classification, mapper path selection, devnode fallback, and holders-directory fallback
Add changelog entry for Fix Linux device-mapper disk paths #3299

Summary by CodeRabbit

Bug Fixes
- Improved handling of Linux device-mapper disks (LVM and encrypted), more reliable device naming and mount-point resolution, and removal of synthetic null paths.
Tests
- Added Linux-focused tests for device-mapper type detection, device-path selection, mount-point fallback behavior, and partition-creation scenarios.

coderabbitai · 2026-05-24T21:39:02Z

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro

Run ID: a7d84eec-40b7-4f00-8558-bfdf2e73f0ba

📥 Commits

Reviewing files that changed from the base of the PR and between 345d6ae and 804f770.

📒 Files selected for processing (5)

CHANGELOG.md
oshi-common/src/main/java/oshi/hardware/common/platform/linux/LinuxHWDiskStore.java
oshi-common/src/test/java/oshi/hardware/common/platform/linux/LinuxHWDiskStoreTest.java
oshi-core-ffm/src/main/java/oshi/hardware/platform/linux/LinuxHWDiskStoreFFM.java
oshi-core/src/main/java/oshi/hardware/platform/linux/LinuxHWDiskStoreJNA.java

✅ Files skipped from review due to trivial changes (1)

CHANGELOG.md

📜 Recent review details

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (11)

GitHub Check: Codacy Static Code Analysis
GitHub Check: Test JDK 21, macos-latest
GitHub Check: Test JDK 21, windows-latest
GitHub Check: Test JDK 25, macos-latest (+ JNA==FFM)
GitHub Check: Test JDK 25, windows-latest (+ JNA==FFM)
GitHub Check: Test JDK 11, macos-latest
GitHub Check: JMH Benchmarks, ubuntu-latest
GitHub Check: Lint (Spotless, Checkstyle, ForbiddenAPIs, Javadoc)
GitHub Check: JMH Benchmarks, macos-latest
GitHub Check: JMH Benchmarks, windows-latest
GitHub Check: Analyze (java)

🧰 Additional context used

🧠 Learnings (2)

📚 Learning: 2026-04-06T04:45:47.644Z

Learnt from: dbwiddis
Repo: oshi/oshi PR: 3121
File: oshi-core/src/main/java/oshi/software/os/linux/LinuxOperatingSystem.java:53-53
Timestamp: 2026-04-06T04:45:47.644Z
Learning: In the oshi/oshi project, only interfaces and classes in the root packages `oshi`, `oshi.hardware`, and `oshi.software.os` are considered the public API. Code in subpackages that represent specific implementations/platforms (e.g., `oshi.software.os.linux`, `oshi.hardware.platform.linux`, and similar subpackages) is implementation detail. When reviewing, do not treat changes to classes in these platform-specific subpackages as public API breaks (for example: making `LinuxOperatingSystem` abstract, narrowing constructor visibility, or adding/removing abstract methods should not be flagged as breaking public API).

Applied to files:

oshi-core/src/main/java/oshi/hardware/platform/linux/LinuxHWDiskStoreJNA.java

📚 Learning: 2026-04-12T19:22:09.716Z

Learnt from: dbwiddis
Repo: oshi/oshi PR: 3149
File: oshi-common/src/main/java/oshi/hardware/common/platform/mac/MacCentralProcessor.java:159-163
Timestamp: 2026-04-12T19:22:09.716Z
Learning: When reviewing OSHI hardware platform code that uses or implements `CentralProcessor`/`PhysicalProcessor.getEfficiency()`, remember the API’s counterintuitive semantics: a *higher* efficiency-class value indicates *greater performance* (lower efficiency). P-cores/“performance cores” should therefore have higher values (e.g., 1) than E-cores/“efficiency cores” (e.g., 0), as documented in the `CentralProcessor` Javadoc. Do not flag code as incorrect solely because ARM_P_CORES or Intel P-cores are assigned higher efficiency values.

Applied to files:

oshi-common/src/main/java/oshi/hardware/common/platform/linux/LinuxHWDiskStore.java

🔇 Additional comments (14)

oshi-core-ffm/src/main/java/oshi/hardware/platform/linux/LinuxHWDiskStoreFFM.java (1)

103-121: LGTM!

oshi-core/src/main/java/oshi/hardware/platform/linux/LinuxHWDiskStoreJNA.java (1)

89-102: LGTM!

oshi-common/src/main/java/oshi/hardware/common/platform/linux/LinuxHWDiskStore.java (6)

22-22: LGTM!

61-62: LGTM!

Also applies to: 69-72

187-220: LGTM!

222-231: LGTM!

233-256: LGTM!

258-291: LGTM!

oshi-common/src/test/java/oshi/hardware/common/platform/linux/LinuxHWDiskStoreTest.java (6)

23-27: LGTM!

29-46: LGTM!

48-76: LGTM!

78-106: LGTM!

108-140: LGTM!

142-161: LGTM!

📝 Walkthrough

Walkthrough

Adds DM UUID classification and utilities in LinuxHWDiskStore to resolve mapper vs raw device paths and mount points (including sysfs holders fallback), integrates this logic into FFM and JNA platform implementations for LVM/CRYPT/device-mapper handling, and adds Linux-only tests and a changelog entry.

Changes

Device mapper encrypted volume mount resolution

Layer / File(s)	Summary
Device mapper path & mount utilities `oshi-common/src/main/java/oshi/hardware/common/platform/linux/LinuxHWDiskStore.java`	Adds `Util` import, `DM_NAME`/`ENCRYPTED_VOLUME`/`DEVICE_MAPPER` constants, DM UUID predicates and model mapping, `getDmDevicePath(dmName, devnode)`, and `getMountPointForDmDevice(mountsMap, dmName, devnode, sysPath)` with mountsMap lookup and sysfs holders fallback.
Unit tests for DM utilities `oshi-common/src/test/java/oshi/hardware/common/platform/linux/LinuxHWDiskStoreTest.java`	Linux-only JUnit tests covering DM model/type inference, `getDmDevicePath` behavior, mountsMap lookup preference, sysfs holders fallback using `@TempDir`, and `addDeviceMapperPartition` cases for LVM/CRYPT/generic DM.
FFM platform integration `oshi-core-ffm/src/main/java/oshi/hardware/platform/linux/LinuxHWDiskStoreFFM.java`	DM enumeration now computes `devModel` via `getModelForDmDevice` and delegates partition creation to `addDeviceMapperPartition(...)`, passing DM metadata and `mountsMap`.
JNA platform integration `oshi-core/src/main/java/oshi/hardware/platform/linux/LinuxHWDiskStoreJNA.java`	DM handling sets `devSerial` from `DM_UUID`, derives `devModel` via `getModelForDmDevice(...)`, and delegates partition creation to `addDeviceMapperPartition(...)`.
Changelog entry `CHANGELOG.md`	Adds PR `#3299` bullet documenting handling of LUKS device-mapper disks without LVM volume names and avoiding synthetic `null` paths.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~25 minutes

Possibly related PRs

oshi/oshi#3077: Related change adding label handling to HWPartition and threading labels through Linux partition creation.

Suggested reviewers

mprins

"🐰 I tunneled through sysfs and maps so deep,
I chased small nulls that tried to creep.
From mapper paths to holders I hop,
I check mounts until I stop.
Hooray — no more surprises from a sleepy disk!"

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 33.33% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title "Fix Linux device-mapper disk paths" directly and concisely summarizes the main change, which is improving the handling of Linux device-mapper disk paths for LUKS encrypted volumes and LVM logical volumes.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

Create PR with unit tests

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

codecov · 2026-05-24T21:40:14Z

Codecov Report

❌ Patch coverage is 48.07692% with 27 lines in your changes missing coverage. Please review.
✅ Project coverage is 75.59%. Comparing base (2e28cda) to head (804f770).

Files with missing lines	Patch %	Lines
...i/hardware/platform/linux/LinuxHWDiskStoreFFM.java	0.00%	15 Missing ⚠️
...i/hardware/platform/linux/LinuxHWDiskStoreJNA.java	0.00%	9 Missing ⚠️
...rdware/common/platform/linux/LinuxHWDiskStore.java	89.28%	0 Missing and 3 partials ⚠️

Additional details and impacted files

@@             Coverage Diff              @@
##             master    #3299      +/-   ##
============================================
+ Coverage     75.55%   75.59%   +0.03%     
  Complexity       76       76              
============================================
  Files           410      410              
  Lines         15814    15830      +16     
  Branches       2546     2546              
============================================
+ Hits          11949    11967      +18     
+ Misses         2384     2372      -12     
- Partials       1481     1491      +10

Flag	Coverage Δ
linux	`40.24% <48.07%> (+0.12%)`	⬆️
macos	`40.78% <0.00%> (-0.04%)`	⬇️
windows	`48.57% <0.00%> (-0.11%)`	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

coderabbitai

🧹 Nitpick comments (1)

oshi-common/src/test/java/oshi/hardware/common/platform/linux/LinuxHWDiskStoreTest.java (1)

27-37: ⚡ Quick win

Add coverage for holders-directory fallback branch.

getMountPointForDmDevice has a third fallback (getDependentNamesFromHoldersDirectory(sysPath)) that is currently untested. A focused test here would harden the new behavior.

Proposed test addition

+import java.io.IOException;
+import java.nio.file.Files;
+import java.nio.file.Path;
+
 import org.junit.jupiter.api.Test;
 import org.junit.jupiter.api.condition.EnabledOnOs;
 import org.junit.jupiter.api.condition.OS;
+import org.junit.jupiter.api.io.TempDir;
@@
 class LinuxHWDiskStoreTest {
+
+    `@TempDir`
+    Path tempDir;
@@
     void testGetMountPointForDmDevice() {
@@
     }
+
+    `@Test`
+    void testGetMountPointForDmDeviceFallsBackToHoldersDirectory() throws IOException {
+        Map<String, String> mountsMap = new HashMap<>();
+        Path sysPath = Files.createDirectories(tempDir.resolve("dm-0"));
+        Files.createDirectories(sysPath.resolve("holders").resolve("sda3"));
+
+        assertThat(
+                LinuxHWDiskStore.getMountPointForDmDevice(mountsMap, "missing", "/dev/dm-0", sysPath.toString()),
+                is("sda3"));
+    }
 }

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In
`@oshi-common/src/test/java/oshi/hardware/common/platform/linux/LinuxHWDiskStoreTest.java`
around lines 27 - 37, Add a new unit test in LinuxHWDiskStoreTest that exercises
the holders-directory fallback of LinuxHWDiskStore.getMountPointForDmDevice:
create a mountsMap that does not contain the target name (so first two fallbacks
fail), then create a temporary sysPath directory (e.g.,
"*/sys/block/dm-0/holders") and place a dummy holder entry matching the
dependent name returned by getDependentNamesFromHoldersDirectory (simulate by
creating a file/symlink with the expected name) and assert that
getMountPointForDmDevice(mountsMap, "<dependentName>", "/dev/dm-0", tempSysPath)
returns the expected mount point from mountsMap for that dependent name; clean
up the temporary directory after the test. Ensure the test references
LinuxHWDiskStore.getMountPointForDmDevice and the sysPath used to trigger
getDependentNamesFromHoldersDirectory.

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Nitpick comments:
In
`@oshi-common/src/test/java/oshi/hardware/common/platform/linux/LinuxHWDiskStoreTest.java`:
- Around line 27-37: Add a new unit test in LinuxHWDiskStoreTest that exercises
the holders-directory fallback of LinuxHWDiskStore.getMountPointForDmDevice:
create a mountsMap that does not contain the target name (so first two fallbacks
fail), then create a temporary sysPath directory (e.g.,
"*/sys/block/dm-0/holders") and place a dummy holder entry matching the
dependent name returned by getDependentNamesFromHoldersDirectory (simulate by
creating a file/symlink with the expected name) and assert that
getMountPointForDmDevice(mountsMap, "<dependentName>", "/dev/dm-0", tempSysPath)
returns the expected mount point from mountsMap for that dependent name; clean
up the temporary directory after the test. Ensure the test references
LinuxHWDiskStore.getMountPointForDmDevice and the sysPath used to trigger
getDependentNamesFromHoldersDirectory.

ℹ️ Review info

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro

Run ID: b70c6b68-48e0-4c13-ba0b-26f84e3aaebe

📥 Commits

Reviewing files that changed from the base of the PR and between 2e28cda and e12c546.

📒 Files selected for processing (5)

CHANGELOG.md
oshi-common/src/main/java/oshi/hardware/common/platform/linux/LinuxHWDiskStore.java
oshi-common/src/test/java/oshi/hardware/common/platform/linux/LinuxHWDiskStoreTest.java
oshi-core-ffm/src/main/java/oshi/hardware/platform/linux/LinuxHWDiskStoreFFM.java
oshi-core/src/main/java/oshi/hardware/platform/linux/LinuxHWDiskStoreJNA.java

📜 Review details

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (11)

GitHub Check: Codacy Static Code Analysis
GitHub Check: Test JDK 25, windows-latest (+ JNA==FFM)
GitHub Check: Test JDK 21, windows-latest
GitHub Check: Test JDK 25, macos-latest (+ JNA==FFM)
GitHub Check: Test JDK 21, macos-latest
GitHub Check: Test JDK 11, macos-latest
GitHub Check: JMH Benchmarks, ubuntu-latest
GitHub Check: JMH Benchmarks, windows-latest
GitHub Check: JMH Benchmarks, macos-latest
GitHub Check: Lint (Spotless, Checkstyle, ForbiddenAPIs, Javadoc)
GitHub Check: Analyze (java)

🧰 Additional context used

🧠 Learnings (2)

📚 Learning: 2026-04-12T19:22:09.716Z

Learnt from: dbwiddis
Repo: oshi/oshi PR: 3149
File: oshi-common/src/main/java/oshi/hardware/common/platform/mac/MacCentralProcessor.java:159-163
Timestamp: 2026-04-12T19:22:09.716Z
Learning: When reviewing OSHI hardware platform code that uses or implements `CentralProcessor`/`PhysicalProcessor.getEfficiency()`, remember the API’s counterintuitive semantics: a *higher* efficiency-class value indicates *greater performance* (lower efficiency). P-cores/“performance cores” should therefore have higher values (e.g., 1) than E-cores/“efficiency cores” (e.g., 0), as documented in the `CentralProcessor` Javadoc. Do not flag code as incorrect solely because ARM_P_CORES or Intel P-cores are assigned higher efficiency values.

Applied to files:

oshi-common/src/main/java/oshi/hardware/common/platform/linux/LinuxHWDiskStore.java

📚 Learning: 2026-04-06T04:45:47.644Z

Learnt from: dbwiddis
Repo: oshi/oshi PR: 3121
File: oshi-core/src/main/java/oshi/software/os/linux/LinuxOperatingSystem.java:53-53
Timestamp: 2026-04-06T04:45:47.644Z
Learning: In the oshi/oshi project, only interfaces and classes in the root packages `oshi`, `oshi.hardware`, and `oshi.software.os` are considered the public API. Code in subpackages that represent specific implementations/platforms (e.g., `oshi.software.os.linux`, `oshi.hardware.platform.linux`, and similar subpackages) is implementation detail. When reviewing, do not treat changes to classes in these platform-specific subpackages as public API breaks (for example: making `LinuxOperatingSystem` abstract, narrowing constructor visibility, or adding/removing abstract methods should not be flagged as breaking public API).

Applied to files:

oshi-core/src/main/java/oshi/hardware/platform/linux/LinuxHWDiskStoreJNA.java

🔇 Additional comments (5)

oshi-common/src/main/java/oshi/hardware/common/platform/linux/LinuxHWDiskStore.java (1)

22-22: LGTM!

Also applies to: 61-73, 187-215

oshi-common/src/test/java/oshi/hardware/common/platform/linux/LinuxHWDiskStoreTest.java (1)

20-25: LGTM!

oshi-core-ffm/src/main/java/oshi/hardware/platform/linux/LinuxHWDiskStoreFFM.java (1)

27-27: LGTM!

Also applies to: 104-110, 116-159

oshi-core/src/main/java/oshi/hardware/platform/linux/LinuxHWDiskStoreJNA.java (1)

29-29: LGTM!

Also applies to: 90-96, 101-132

CHANGELOG.md (1)

17-17: LGTM!

coderabbitai

Actionable comments posted: 1

🧹 Nitpick comments (1)

oshi-common/src/main/java/oshi/hardware/common/platform/linux/LinuxHWDiskStore.java (1)

242-250: 💤 Low value

Consider eliminating redundant map lookup when dmName is blank.

When dmName is blank, devicePath equals devnode, causing the method to check mountsMap for devnode twice: once at line 245 and again at line 249. While this doesn't affect correctness, it introduces a minor inefficiency.

♻️ Optional refactor to eliminate the duplicate lookup

 protected static String getMountPointForDmDevice(Map<String, String> mountsMap, String dmName, String devnode,
         String sysPath) {
     String devicePath = getDmDevicePath(dmName, devnode);
-    String mountPoint = mountsMap.get(devicePath);
-    if (mountPoint != null) {
-        return mountPoint;
-    }
-    return mountsMap.getOrDefault(devnode, getDependentNamesFromHoldersDirectory(sysPath));
+    return mountsMap.getOrDefault(devicePath,
+            mountsMap.getOrDefault(devnode, getDependentNamesFromHoldersDirectory(sysPath)));
 }

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In
`@oshi-common/src/main/java/oshi/hardware/common/platform/linux/LinuxHWDiskStore.java`
around lines 242 - 250, The method getMountPointForDmDevice does two lookups for
the same key when dmName is blank because devicePath equals devnode; change the
logic to perform a single mountsMap lookup for devicePath, return it if found,
and only perform the second lookup for devnode when devicePath and devnode
differ, otherwise skip the redundant mountsMap.get(devnode) and directly return
getDependentNamesFromHoldersDirectory(sysPath) when the first lookup was null.

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In
`@oshi-common/src/test/java/oshi/hardware/common/platform/linux/LinuxHWDiskStoreTest.java`:
- Around line 152-156: Add an implementation of the abstract updateAttributes()
method inside the TestLinuxHWDiskStore class to satisfy the HWDiskStore
contract: override updateAttributes() (using the exact signature from
LinuxHWDiskStore/HWDiskStore) and provide a minimal no-op or test-appropriate
body (e.g., an empty method or simple attribute stubs). Be sure to annotate with
`@Override` and place it inside the TestLinuxHWDiskStore class so the class
compiles.

---

Nitpick comments:
In
`@oshi-common/src/main/java/oshi/hardware/common/platform/linux/LinuxHWDiskStore.java`:
- Around line 242-250: The method getMountPointForDmDevice does two lookups for
the same key when dmName is blank because devicePath equals devnode; change the
logic to perform a single mountsMap lookup for devicePath, return it if found,
and only perform the second lookup for devnode when devicePath and devnode
differ, otherwise skip the redundant mountsMap.get(devnode) and directly return
getDependentNamesFromHoldersDirectory(sysPath) when the first lookup was null.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

Push a commit to this branch (recommended)
Create a new PR with the fixes

ℹ️ Review info

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro

Run ID: 29876436-465d-4041-9aff-8ac30a2b3b5e

📥 Commits

Reviewing files that changed from the base of the PR and between 259fd40 and 345d6ae.

📒 Files selected for processing (5)

CHANGELOG.md
oshi-common/src/main/java/oshi/hardware/common/platform/linux/LinuxHWDiskStore.java
oshi-common/src/test/java/oshi/hardware/common/platform/linux/LinuxHWDiskStoreTest.java
oshi-core-ffm/src/main/java/oshi/hardware/platform/linux/LinuxHWDiskStoreFFM.java
oshi-core/src/main/java/oshi/hardware/platform/linux/LinuxHWDiskStoreJNA.java

✅ Files skipped from review due to trivial changes (1)

CHANGELOG.md

📜 Review details

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)

GitHub Check: Codacy Static Code Analysis
GitHub Check: Analyze (java)

🧰 Additional context used

🧠 Learnings (2)

📚 Learning: 2026-04-06T04:45:47.644Z

Learnt from: dbwiddis
Repo: oshi/oshi PR: 3121
File: oshi-core/src/main/java/oshi/software/os/linux/LinuxOperatingSystem.java:53-53
Timestamp: 2026-04-06T04:45:47.644Z
Learning: In the oshi/oshi project, only interfaces and classes in the root packages `oshi`, `oshi.hardware`, and `oshi.software.os` are considered the public API. Code in subpackages that represent specific implementations/platforms (e.g., `oshi.software.os.linux`, `oshi.hardware.platform.linux`, and similar subpackages) is implementation detail. When reviewing, do not treat changes to classes in these platform-specific subpackages as public API breaks (for example: making `LinuxOperatingSystem` abstract, narrowing constructor visibility, or adding/removing abstract methods should not be flagged as breaking public API).

Applied to files:

oshi-core/src/main/java/oshi/hardware/platform/linux/LinuxHWDiskStoreJNA.java

📚 Learning: 2026-04-12T19:22:09.716Z

Learnt from: dbwiddis
Repo: oshi/oshi PR: 3149
File: oshi-common/src/main/java/oshi/hardware/common/platform/mac/MacCentralProcessor.java:159-163
Timestamp: 2026-04-12T19:22:09.716Z
Learning: When reviewing OSHI hardware platform code that uses or implements `CentralProcessor`/`PhysicalProcessor.getEfficiency()`, remember the API’s counterintuitive semantics: a *higher* efficiency-class value indicates *greater performance* (lower efficiency). P-cores/“performance cores” should therefore have higher values (e.g., 1) than E-cores/“efficiency cores” (e.g., 0), as documented in the `CentralProcessor` Javadoc. Do not flag code as incorrect solely because ARM_P_CORES or Intel P-cores are assigned higher efficiency values.

Applied to files:

oshi-common/src/main/java/oshi/hardware/common/platform/linux/LinuxHWDiskStore.java

🪛 GitHub Actions: Pull Request CI / 0_Test JDK 25, ubuntu-latest (+ JNA==FFM).txt