| Message ID | 20230406021939.2526130-1-trini@konsulko.com |
|---|---|
| State | Accepted |
| Commit | af2fde49fe53810224c67d8d1cbc8080466da907 |
| Delegated to: | Tom Rini |
| Headers | show |
| Series | [1/1] pytest: Use --lazy with umount | expand |
Hi Tom, On Thu, 6 Apr 2023 at 14:19, Tom Rini <trini@konsulko.com> wrote: > > Sometimes when doing tests on real hardware we sometimes run in to the > case where some of these mounts haven't been fully flushed. Using the > --lazy option with umount will allow us to continue while letting the OS > handle flushing the data out still. > > Signed-off-by: Tom Rini <trini@konsulko.com> > --- > test/py/tests/test_ut.py | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) Reviewed-by: Simon Glass <sjg@chromium.org> I wonder if these ever actually succeed later on, or do they remain mounted forever? Regards, SImon
On Fri, Apr 07, 2023 at 05:31:17PM +1200, Simon Glass wrote: > Hi Tom, > > On Thu, 6 Apr 2023 at 14:19, Tom Rini <trini@konsulko.com> wrote: > > > > Sometimes when doing tests on real hardware we sometimes run in to the > > case where some of these mounts haven't been fully flushed. Using the > > --lazy option with umount will allow us to continue while letting the OS > > handle flushing the data out still. > > > > Signed-off-by: Tom Rini <trini@konsulko.com> > > --- > > test/py/tests/test_ut.py | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > Reviewed-by: Simon Glass <sjg@chromium.org> > > I wonder if these ever actually succeed later on, or do they remain > mounted forever? They complete the unmount with this change done, yes.
Hi Tom, On Sat, 8 Apr 2023 at 02:36, Tom Rini <trini@konsulko.com> wrote: > > On Fri, Apr 07, 2023 at 05:31:17PM +1200, Simon Glass wrote: > > Hi Tom, > > > > On Thu, 6 Apr 2023 at 14:19, Tom Rini <trini@konsulko.com> wrote: > > > > > > Sometimes when doing tests on real hardware we sometimes run in to the > > > case where some of these mounts haven't been fully flushed. Using the > > > --lazy option with umount will allow us to continue while letting the OS > > > handle flushing the data out still. > > > > > > Signed-off-by: Tom Rini <trini@konsulko.com> > > > --- > > > test/py/tests/test_ut.py | 4 ++-- > > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > Reviewed-by: Simon Glass <sjg@chromium.org> > > > > I wonder if these ever actually succeed later on, or do they remain > > mounted forever? > > They complete the unmount with this change done, yes. That's great to hear. I wonder if we should try a 'sync' beforehand? So long as it is short it shouldn't matter, but if it dragged on for a minute or two it might conflict with another job. I don't have a good understanding of what is going on in the kernel. Regards, Simon
On Sat, Apr 08, 2023 at 06:55:14AM +1200, Simon Glass wrote: > Hi Tom, > > On Sat, 8 Apr 2023 at 02:36, Tom Rini <trini@konsulko.com> wrote: > > > > On Fri, Apr 07, 2023 at 05:31:17PM +1200, Simon Glass wrote: > > > Hi Tom, > > > > > > On Thu, 6 Apr 2023 at 14:19, Tom Rini <trini@konsulko.com> wrote: > > > > > > > > Sometimes when doing tests on real hardware we sometimes run in to the > > > > case where some of these mounts haven't been fully flushed. Using the > > > > --lazy option with umount will allow us to continue while letting the OS > > > > handle flushing the data out still. > > > > > > > > Signed-off-by: Tom Rini <trini@konsulko.com> > > > > --- > > > > test/py/tests/test_ut.py | 4 ++-- > > > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > > > Reviewed-by: Simon Glass <sjg@chromium.org> > > > > > > I wonder if these ever actually succeed later on, or do they remain > > > mounted forever? > > > > They complete the unmount with this change done, yes. > > That's great to hear. I wonder if we should try a 'sync' beforehand? > So long as it is short it shouldn't matter, but if it dragged on for a > minute or two it might conflict with another job. I don't have a good > understanding of what is going on in the kernel. Based on a quick read of the man page, I think --lazy itself is just what we want here.
Hi Tom, On Sat, 8 Apr 2023 at 07:46, Tom Rini <trini@konsulko.com> wrote: > > On Sat, Apr 08, 2023 at 06:55:14AM +1200, Simon Glass wrote: > > Hi Tom, > > > > On Sat, 8 Apr 2023 at 02:36, Tom Rini <trini@konsulko.com> wrote: > > > > > > On Fri, Apr 07, 2023 at 05:31:17PM +1200, Simon Glass wrote: > > > > Hi Tom, > > > > > > > > On Thu, 6 Apr 2023 at 14:19, Tom Rini <trini@konsulko.com> wrote: > > > > > > > > > > Sometimes when doing tests on real hardware we sometimes run in to the > > > > > case where some of these mounts haven't been fully flushed. Using the > > > > > --lazy option with umount will allow us to continue while letting the OS > > > > > handle flushing the data out still. > > > > > > > > > > Signed-off-by: Tom Rini <trini@konsulko.com> > > > > > --- > > > > > test/py/tests/test_ut.py | 4 ++-- > > > > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > > > > > Reviewed-by: Simon Glass <sjg@chromium.org> > > > > > > > > I wonder if these ever actually succeed later on, or do they remain > > > > mounted forever? > > > > > > They complete the unmount with this change done, yes. > > > > That's great to hear. I wonder if we should try a 'sync' beforehand? > > So long as it is short it shouldn't matter, but if it dragged on for a > > minute or two it might conflict with another job. I don't have a good > > understanding of what is going on in the kernel. > > Based on a quick read of the man page, I think --lazy itself is just > what we want here. OK good. Regards, Simon
On Wed, Apr 05, 2023 at 10:19:39PM -0400, Tom Rini wrote: > Sometimes when doing tests on real hardware we sometimes run in to the > case where some of these mounts haven't been fully flushed. Using the > --lazy option with umount will allow us to continue while letting the OS > handle flushing the data out still. > > Signed-off-by: Tom Rini <trini@konsulko.com> > Reviewed-by: Simon Glass <sjg@chromium.org> Applied to u-boot/master, thanks!
diff --git a/test/py/tests/test_ut.py b/test/py/tests/test_ut.py index e8c8a6d6bd59..0b45863b4385 100644 --- a/test/py/tests/test_ut.py +++ b/test/py/tests/test_ut.py @@ -213,7 +213,7 @@ booti ${kernel_addr_r} ${ramdisk_addr_r} ${fdt_addr_r} str(exc)) finally: if mounted: - u_boot_utils.run_and_log(cons, 'sudo umount %s' % mnt) + u_boot_utils.run_and_log(cons, 'sudo umount --lazy %s' % mnt) if loop: u_boot_utils.run_and_log(cons, 'sudo losetup -d %s' % loop) @@ -274,7 +274,7 @@ label Fedora-Workstation-armhfp-31-1.9 (5.3.7-301.fc31.armv7hl) str(exc)) finally: if mounted: - u_boot_utils.run_and_log(cons, 'sudo umount %s' % mnt) + u_boot_utils.run_and_log(cons, 'sudo umount --lazy %s' % mnt) if loop: u_boot_utils.run_and_log(cons, 'sudo losetup -d %s' % loop)
Sometimes when doing tests on real hardware we sometimes run in to the case where some of these mounts haven't been fully flushed. Using the --lazy option with umount will allow us to continue while letting the OS handle flushing the data out still. Signed-off-by: Tom Rini <trini@konsulko.com> --- test/py/tests/test_ut.py | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)