Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add WithLoopDevices to report loop devices #310

Merged
merged 6 commits into from
Apr 4, 2022
Merged

Add WithLoopDevices to report loop devices #310

merged 6 commits into from
Apr 4, 2022

Conversation

Itxaka
Copy link
Contributor

@Itxaka Itxaka commented Mar 21, 2022

Currently we skipp over all loop devices in the system and with no
possibility of reporting those.

This patch introduces a new option to Block that allows us to report
loop devices as disk and their partitions like if they were normal
disks.

This patch does not modify any existing functionality or alters anything
with the default values.

With WithLoopDevices enabled this reports the same info for loop devices
as with other disks, including size, fs, mountpoints and so on.

Signed-off-by: Itxaka igarcia@suse.com

@Itxaka
Copy link
Contributor Author

Itxaka commented Mar 24, 2022

@fromanirh any comments on this? thanks!

@ffromani
Copy link
Collaborator

thanks @Itxaka for your contribution! I'll review today/tomorrow

@jaypipes
Copy link
Owner

@Itxaka what is the use case for a go-hardware library tracking loopback devices? :)

@Itxaka
Copy link
Contributor Author

Itxaka commented Mar 24, 2022

well, we could make the same question about returning mount points and filesystems no? Those are not hardware related at all, more like system status, so thinking in terms of ghw providing info about the current system in which its running, I want to see all the mountpoints, including those from loop devices which are mounted. I.E. I want to scan all mountpoints in the system to do something with them, report of scan or whatever, loop devices mounted are part of that system.

Thats the best I can do to sell this feature LOL :P

If you want a specific use case, we use loop devices in our installer[0] to test real installs, not really to a real filesystem, but to a loop device so we dont break any real disks, so we do some partition discovery and mounting. We currently use lsblk directly, but it would be much nicer to use a pure golang lib instead of depending on lsblk. Having loop mounts discovery in ghw helps us :)

[0] https://github.com/rancher-sandbox/elemental

@jaypipes
Copy link
Owner

well, we could make the same question about returning mount points and filesystems no? Those are not hardware related at all, more like system status, so thinking in terms of ghw providing info about the current system in which its running, I want to see all the mountpoints, including those from loop devices which are mounted. I.E. I want to scan all mountpoints in the system to do something with them, report of scan or whatever, loop devices mounted are part of that system.

Thats the best I can do to sell this feature LOL :P

If you want a specific use case, we use loop devices in our installer[0] to test real installs, not really to a real filesystem, but to a loop device so we dont break any real disks, so we do some partition discovery and mounting. We currently use lsblk directly, but it would be much nicer to use a pure golang lib instead of depending on lsblk. Having loop mounts discovery in ghw helps us :)

[0] https://github.com/rancher-sandbox/elemental

Fair enough. You've sold me on your use case.

I'll do a full review of the PR shortly.

Itxaka added 2 commits March 25, 2022 11:38
Currently we skipp over all loop devices in the system and with no
possibility of reporting those.

This patch introduces a new option to Block that allows us to report
loop devices as disk and their partitions like if they were normal
disks.

This patch does not modify any existing functionality or alters anything
with the default values.

With WithLoopDevices enabled this reports the same info for loop devices
as with other disks, including size, fs, mountpoints and so on.

Signed-off-by: Itxaka <igarcia@suse.com>
@Itxaka
Copy link
Contributor Author

Itxaka commented Mar 30, 2022

any update on this @jaypipes ?

Signed-off-by: Itxaka <igarcia@suse.com>
Comment on lines 334 to 338
if driveType == DRIVE_TYPE_LOOP && size == 0 {
// Do nothing for empty loop devices
// There can be several loop devices present on /dev but that doesnt mean they are in use
// With this we skip any non-used loop devices
} else {
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would prefer to just return all the loop devices that are listed by the OS, regardless of their size. Calling programs can filter out returned results any way they want.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thing is, if you mount something on a loop device, several loop devices will appear in /dev, even if not mounted. This was a kind fo fix to report only those loop devices in use.

$ sudo losetup -f --show cOS-Seed-green-0.8.8-g8522da85-x86_64.iso 
/dev/loop0

$ ls /dev/loop*
/dev/loop0  /dev/loop2  /dev/loop4  /dev/loop6  /dev/loop-control
/dev/loop1  /dev/loop3  /dev/loop5  /dev/loop7

$ sudo blkid |grep loop
/dev/loop0: BLOCK_SIZE="2048" UUID="2022-03-23-20-47-00-00" LABEL="COS_LIVE" TYPE="iso9660" PTTYPE="dos"

So in reality, in this situation, only the loop0 device is being used, the rest are there for some reason I guess, but not used. Returning unused loop devices seemed to me a waste of user time filtering those out as they are never gonna need them for anything.

Thoughts?

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Itxaka OK, I guess I can get behind that reasoning :)

Do me a favor though... in order to reduce the number of lines of code changed here, can you edit the above to this instead?

if storageController == STORAGE_CONTROLLER_LOOP && size == 0 {
    // We don't care about unused loop devices...
    continue
}

and please place above the d := &Disk{...} definition line.

@@ -29,6 +29,7 @@ const (
DRIVE_TYPE_FDD // Floppy disk drive
DRIVE_TYPE_ODD // Optical disk drive
DRIVE_TYPE_SSD // Solid-state drive
DRIVE_TYPE_LOOP // loop device
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm questioning whether "loop" should be a DRIVE_TYPE... is it really a type of drive? I'm not sure... maybe we should make a new DRIVE_TYPE_VIRTUAL or DRIVE_TYPE_PSEUDO.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

DRIVE_TYPE_VIRTUAL sounds good to me. I wanted to return something for this field but not overcomplicate things. virtual seems perfect

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK, let's go with DRIVE_TYPE_VIRTUAL then, @Itxaka.

@@ -137,6 +137,9 @@ type Option struct {
// to learn about the system resources.
PathOverrides PathOverrides

// LoopDevices optionally allows reporting disk/partitions that are loop devices
LoopDevices *bool
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm tempted to say let's get rid of this option and just always process loop devices, and let callers filter out any results the want... @fromanirh what do you think?

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Itxaka yeah, just remove this config option... if there is a huge demand for it, we can always add an option in the future.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey! I didn't had time to think this change (overall PR not this specific bit) deep enough. Will do next week. In general I tend to agree to add to the API surface gradually.

 - Remove option to show loopdevices
 - Change storage/type to virtual
 - Simplify empty loop device skipping
 - Always report loop devices

Signed-off-by: Itxaka <igarcia@suse.com>
@Itxaka Itxaka requested review from jaypipes and ffromani April 1, 2022 09:49
@Itxaka
Copy link
Contributor Author

Itxaka commented Apr 1, 2022

umm, failing on ubuntu but I cant reproduce it locally. As that its picking up the underlaying os devices Im sure there is something wrong in the code..Will try to debug

Signed-off-by: Itxaka <igarcia@suse.com>
@Itxaka
Copy link
Contributor Author

Itxaka commented Apr 1, 2022

Found it, missing a value :D

@@ -93,6 +96,7 @@ const (
STORAGE_CONTROLLER_NVME // Non-volatile Memory Express
STORAGE_CONTROLLER_VIRTIO // Virtualized storage controller/driver
STORAGE_CONTROLLER_MMC // Multi-media controller (used for mobile phone storage devices)
STORAGE_CONTROLLER_VIRTUAL // virtual controller, i.e. for a loop device
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry @Itxaka I didn't make myself clear in the original review... I thought STORAGE_CONTROLLER_LOOP was good. It's only the DRIVE_TYPE_LOOP that I wanted to change to DRIVE_TYPE_VIRTUAL... Can we swtich the storage controller back please? :)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done!

Set back the storage controller to identify loop devices and try to fix
a potential problem with running the generic block tests in a host with
loop devices.

Signed-off-by: Itxaka <igarcia@suse.com>
@Itxaka Itxaka requested a review from jaypipes April 4, 2022 07:31
Copy link
Owner

@jaypipes jaypipes left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Very nice work, @Itxaka thank you!

Comment on lines +45 to +52
// Skip loop devices on generic tests as we don't know what the underlying system is going to have
// And loop devices don't have Serial Numbers for example.
for _, d := range disks {
if d.StorageController != block.STORAGE_CONTROLLER_LOOP {
d0 = d
break
}
}
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

@jaypipes jaypipes merged commit 2ea05cb into jaypipes:main Apr 4, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants