Message ID | 20230810111317.25273-1-dwagner@suse.de (mailing list archive) |
---|---|
Headers | show |
Series | Switch to allowed_host | expand |
On Aug 10, 2023 / 13:13, Daniel Wagner wrote: > I've updated the series accoring the feedback. Also added the mentioned > _nvmet_target_{setup|cleanup} helpers which reduced a lot of code. > Roughly 350 lines code less after the refactoring. > > Maybe it's possible to refactor even more, e.g. this snippet > > > local nvmedev > nvmedev=$(_find_nvme_dev "${def_subsysnqn}") > cat "/sys/block/${nvmedev}n1/uuid" > cat "/sys/block/${nvmedev}n1/wwid" > > could be moved into _nvme_connect_subsys(). Though there are quiet a few tests > which want the nvmedev later on for something like > > _run_fio_verify_io --size="${nvme_img_size}" \ > --filename="/dev/${nvmedev}n1" > > So we could return the nvmedev from _nvme_connect_subsys() but I don't know if > this a good idea. IMO, it is a good idea to make _nvme_connect_subsys() return the device. The similar function _nvmet_passthru_target_connect() does that, so it is another small goodness to have consistency between the two. > FWIW, it would also fix the current problem we face with > nvme/047 which seems to lack the second _find_nvme_dev() call. I posted the fix patch for the nvme/047 problem reflecting your comments. I hope that fix settled before further refactoring. It is a fun to see the much of the boiler plates go away with the series :) Thanks. I provided two minor comments on the 5th patch and 10th patch. Other than that, this series looks good to me. Also I did another trial run, and saw no regression. Good.
On Fri, Aug 11, 2023 at 06:16:45AM +0000, Shinichiro Kawasaki wrote: > > So we could return the nvmedev from _nvme_connect_subsys() but I don't know if > > this a good idea. > > IMO, it is a good idea to make _nvme_connect_subsys() return the device. The > similar function _nvmet_passthru_target_connect() does that, so it is another > small goodness to have consistency between the two. Sure, I'll look into this when I remove the udev trigger filter code again which resulted in this series. But let's get this series sorted out first. > > FWIW, it would also fix the current problem we face with > > nvme/047 which seems to lack the second _find_nvme_dev() call. > > I posted the fix patch for the nvme/047 problem reflecting your comments. I hope > that fix settled before further refactoring. Yep, let's get the bug fix in first. > It is a fun to see the much of the boiler plates go away with the > series :) Ineed, makes the test way smaller. BTW, what do you think about removing nvme/006 and nvme/007? They are basically doing nothing anymore except setting up a target with either device or file backing. We exercise this code now in all the other tests. So this is bit redundant IMO. > Thanks. I provided two minor comments on the 5th patch and 10th patch. Other > than that, this series looks good to me. Also I did another trial run, and > saw no regression. Good. I've updated the series accordingly. Let me run a quick test and then I post the update.
On Aug 11, 2023 / 09:00, Daniel Wagner wrote: [...] > BTW, what do you think about removing nvme/006 and nvme/007? They are > basically doing nothing anymore except setting up a target with either > device or file backing. We exercise this code now in all the other > tests. So this is bit redundant IMO. I think the test cases are meaningful. They confirm that target set up feature is working good. When other test cases fail, we can refer nvme/006 and nvme/007 results and see if the failure cause is in target set up or not.
On Thu, Aug 17, 2023 at 02:55:25AM +0000, Shinichiro Kawasaki wrote: > On Aug 11, 2023 / 09:00, Daniel Wagner wrote: > [...] > > BTW, what do you think about removing nvme/006 and nvme/007? They are > > basically doing nothing anymore except setting up a target with either > > device or file backing. We exercise this code now in all the other > > tests. So this is bit redundant IMO. > > I think the test cases are meaningful. They confirm that target set up feature > is working good. When other test cases fail, we can refer nvme/006 and nvme/007 > results and see if the failure cause is in target set up or not. Fair enough. If I want to cut execution time I can just exclude those test from the run.