sinhaparth5 commented on PR #67536: URL: https://github.com/apache/doris/pull/67536#issuecomment-6121582036
Reworked this along the lines you described. `get_device_names()` no longer classifies devices by name at all — for each dev_t from `/proc/partitions` it follows `/sys/dev/block/<major>:<minor>` and checks that device's sysfs directory for a `partition` file. If it's there, the device is a partition and its disk is the parent directory's name; if not, it's already a whole device and keeps its own name. That's the same signal your write-up described (kernel device number as identity, sysfs to tell partition from parent), just without the `/sys/block` enumeration pass, since keying off the dev_t already in `/proc/partitions` plus the per-device sysfs lookup covers the same ground with a smaller diff. Added `DiskInfo::disk_name_from_sysfs_path()` as the pure piece of this — it takes a resolved sysfs path and a partition flag and returns the disk name — so the unit test can exercise sda1, nvme0n1p1, mmcblk0p1, md127, and dm-0/dm-1 with fabricated paths instead of depending on whatever happens to be mounted on the CI host. `strip_partition_suffix()` and the `dm-` special case are gone. Verified two ways on a throwaway VM: built be-common and be-core (ASAN) and ran `DiskInfoTest.*`, which passes; and separately walked the VM's actual `/proc/partitions` and `/sys/dev/block` by hand to confirm the resolution logic matches real kernel behavior (sda/sda1/sda14/sda15 all resolve to sda, loop devices resolve to themselves), not just the synthetic test paths. `get_disk_devices()`'s major:minor matching for the LVM mount case didn't need to change — it was already keying off dev_t rather than names, so it's unaffected by how the disk names themselves get resolved. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
