** Changed in: linux (Ubuntu)
Assignee: Eric Desrochers (slashd) => (unassigned)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1856871
Title:
i/o error if next unused loop device is queried
** Changed in: linux (Ubuntu)
Status: Incomplete => In Progress
** Changed in: linux (Ubuntu)
Importance: Undecided => Medium
** Changed in: linux (Ubuntu)
Assignee: (unassigned) => Mauricio Faria de Oliveira (mfo)
** Changed in: parted (Ubuntu)
Status: New => Invalid
**
The upstream proposal fix that mfo and I worked on has been applied:
https://patchwork.kernel.org/project/linux-
block/patch/20210222154123.61797-1-...@canonical.com/
- Eric
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
** Changed in: udev (Ubuntu)
Status: New => Invalid
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1856871
Title:
i/o error if next unused loop device is queried
To manage notifications
marking invalid for systemd, as i think we all agree it's not an issue
caused by systemd, but please feel free to re-mark it for systemd if i'm
incorrect
** Changed in: systemd (Ubuntu)
Status: New => Invalid
--
You received this bug notification because you are a member of Ubuntu
Bugs,
I reproduced the behaviour using 5.5 upstream kernel by:
1) Mounting a loop device
2) Setup frace for all loop function for capture purposes
3) Then umount the loop device
trace_pipe reveal the following:
"umount-1850 [000] 471.727511: loop_release_xfer <-__loop_clr_fd"
As cascardo
I reproduced the behaviour using 5.5 upstream kernel by:
1) Mounting a loop device
2) Setup frace for all loop function for capture purposes
3) Then umount the loop device
trace_pipe reveal the following:
"umount-1850 [000] 471.727511: loop_release_xfer <-__loop_clr_fd"
As cascardo
so 2 things come to my mind right now
Does the kernel (loop driver) do the right thing by not clear/reset the
loop device' stats after the umount/detached operation ?
and/or
Does parted need to be smarter and not only based is detection on stat()
to assume if its a legit device or not to be
so 2 things come to my mind right now
Does the kernel (loop driver) do the right thing by not clear/reset the
loop device' stats after the umount/detached operation ?
and/or
Does parted need to smarter and not only based is detection only on
stat() ?
Let's circle back on Jan 2020.
** Also
Ok so in fact the inconsistency is due to "parted" that will try to
probe devices iff the given block device return informations from
stat(), regardless if the block device is available or not.
Seems like the only trigger/criteria is the stat() return. Since the
loop device stat doesn't
Agreed with your comment #11
will start a discussion with the linux-block maintainer.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1856871
Title:
i/o error if next unused loop device is queried
It then might be a problem with "/dev/loop-control" device node. Which
dynamically find or allocate a free device, but also add and remove loop
devices from the running system.
# drivers/block/loop.c
2090 static void loop_remove(struct loop_device *lo)
2091 {
2092
Exactly my point about consistency. They should either return EIO in
both cases or succeed in both cases. Which behavior will depend on: 1)
which is the easier solution; 2) what upstream thinks is okay.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is
@thadeu,
To respond your question "What is the exact problem this is causing?"
So far it's not causing much problem, it's pretty harmless, but while
running sosreport block plugin (which most Canonical customer uses) it
may lead to output "blk" error to the stderr and save syslog ||
kern.log.
so the problem is inside the block layer ?
More likely the loop driver not undoing something it does when a file is
attached to it. But could as well be something related to the multiqueue
support, so could still be something in the block layer. Still needs
investigation.
Anyway, as this is not
I did some quick testing and it seems this happens on whatever loop
device that had a file attached and then detached. No matter if it's the
next available or not. So, if you create a new loop device without ever
attaching a file to it, it seems the block layer is not setup
sufficiently so any
FWIW snapd mounts and unmounts a squashfs on startup to determine
whether the system can mount squashfs's. It does this using mount, and
cleans up with umount -l. That is, it's not via systemd in this instance
in particular.
I'm setting it as invalid for snapd, but if this behaviour is somehow
# parted code (3.3-1) from focal
-
libparted/arch/linux.c:
.
=> if (fsync (fd) < 0 || close (fd) < 0)
if (ped_exception_throw (
PED_EXCEPTION_WARNING,
losetup -l
NAME SIZELIMIT OFFSET AUTOCLEAR RO BACK-FILE
DIO LOG-SEC
/dev/loop1 0 0 1 1 /var/lib/snapd/snaps/core_7270.snap
0 512
/dev/loop2 0 0 1 1 /var/lib/snapd/snaps/core_8268.snap
0 512
/dev/loop0
Talking with mvo (snap team) on the subject trying to eliminate some
components:
[09:48:27] so snapd does not do anything "special" with block devices
beside using them
[09:48:39] it uses the standard system mount units to do that
[09:49:01] so if you see strange things with extra block
Interesting fact,
If I modified "snapd.service" to prevent snapd to run and reboot. I
don't get the problem with the first unused loop device which is
/dev/loop0 since nothing is using a loop device.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is
** Description changed:
This is reproducible in Bionic and late.
Here's an example running 'focal':
$ lsb_release -cs
focal
$ uname -r
5.3.0-24-generic
The error is:
blk_update_request: I/O error, dev loop2, sector 0
+
+ and on more recent kernel:
+
+ kernel:
I also filed a sosreport upstream issue, because I believe sosreport
shouldn't try to query "unused" block device such as loop device.
https://github.com/sosreport/sos/issues/1897
but situation remain that there is something going wrong with loop
device and systemd/systemd-udevd at boot as
Booting with "systemd.log_level=debug" revealed:
Dec 18 17:26:22 ubuntu systemd-udevd[1326]: value '[dmi/id]sys_vendor' is 'QEMU'
Dec 18 17:26:22 ubuntu systemd-udevd[1326]: created db file
'/run/udev/data/b7:2' for '/devices/virtual/block/loop2'
Dec 18 17:26:22 ubuntu systemd[1]:
** Description changed:
This is reproducible in Bionic and late.
Here's an example running 'focal':
$ lsb_release -cs
focal
$ uname -r
5.3.0-24-generic
+ The error is:
+ blk_update_request: I/O error, dev loop2, sector 0
+
How to trigger it:
-
$ sosreport -o block
25 matches
Mail list logo
