Repository navigation
Conversation
…to its device (Niko1221#4493) storage_of gave up on any mount whose source was not a /dev path, so a model copied to /dev/shm, a btrfs subvolume (/dev/nvme0n1p2[/@home]) or an NFS export all reported "the drive holding the model files could not be identified". Read FSTYPE with SOURCE: tmpfs and friends are kind ram, network filesystems kind network (the host stays out of the report), and a btrfs [subvolume] suffix is stripped before lsblk. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem and result
Fixes #4493.
storage_of(strata_cli/bench_facts.py) read the mount's SOURCE and gave up when it was not a/dev/path. A model copied to/dev/shm(tmpfs), a btrfs subvolume (SOURCE/dev/nvme0n1p2[/@home], theFedora default) and an NFS export (
host:/export) all producedhardware.storage: nullwith the reason "the driveholding the model files could not be identified". Our run in #4468 shows it for /dev/shm.
After: FSTYPE is read with SOURCE. tmpfs, ramfs, devtmpfs and hugetlbfs report
{"kind": "ram", "model": "tmpfs", "bus": "memory"}; nfs*, cifs, smb*, 9p, ceph, glusterfs and fuse.sshfs report{"kind": "network", "model": "<fstype>", "bus": "network"}(the host name stays out of the report); a btrfs[subvolume]suffix is strippedbefore
lsblk, so the disk is found as for any other device. Other sources still give None with the old reason.Related discussion
#4493
Approach
Linux branch of
storage_ofonly; Windows and thelsblkwalk are unchanged. The README line renders as"ram tmpfs (memory)" through the existing "%s %s (%s)" format.
validate()checks that the storage field exists,not its kind values, so the two new kinds pass as they are.
Validation
Passed:
python3.12 -m unittest tests.terminal.test_bench_facts_storage tests.terminal.test_bench_standard tests.terminal.test_bench_facts_amd:Ran 82 tests in 43.762s, OK (1 skipped). Strata Control 0.1.52's bundled Python 3.12.15, Ubuntu 26.10, this branch (main 46c152a + this commit).
tests/terminal/test_bench_facts_storage.pyon unchanged main: Ran 5 tests in 0.002s FAILED (failures=3) (tmpfs, NFS and btrfs cases fail; the plain-device and unknown-source cases pass as before).Failed:
Not run:
strata bench runwith this branch (the real /dev/shm case is only covered by the unit test with findmnt's output string).Limits
🤖 Generated with Claude Code