From: Karel Zak <kzak@redhat.com>
To: Phillip Susi <psusi@ubuntu.com>
Cc: Francis Moreau <francis.moro@gmail.com>,
"Dale R. Worley" <worley@alum.mit.edu>,
util-linux@vger.kernel.org, gabeblack@chromium.org,
gwendal@chromium.org
Subject: Re: losetup on a image file containing (GPT) partition doesn't create partition devices
Date: Wed, 3 Dec 2014 09:36:17 +0100 [thread overview]
Message-ID: <20141203083617.GD1994@x2.net.home> (raw)
In-Reply-To: <547E1337.1080702@ubuntu.com>
On Tue, Dec 02, 2014 at 02:29:59PM -0500, Phillip Susi wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 10/27/2014 4:16 PM, Mike Frysinger wrote:
> > we've been tracking the same bug in Chromium OS:
> > http://crbug.com/411693 basically, under load, using `losetup -P`
> > randomly fails to create the relevant partition nodes. atm we have
> > hacks in place to call `blockdev --rereadpt` when it looks like the
> > kernel has failed us.
> >
> > it would be nice if the kernel didn't ignore the result of the
> > ioctl thus allowing all errors to go unnoticed. you can see this
> > in drivers/block/loop.c where it calls ioctl_by_bdev multiple times
> > and doesn't check the return value.
> >
> > since all current kernels are broken though, and might be for the
> > foreseeable future, having losetup issue the ioctl itself might be
> > a good tradeoff. i think it'd trigger unnecessary overhead
> > (rescanning the device after it already worked), but seems better
> > than having losetup try and check other sources (like if arbitrary
> > partition nodes were created).
>
> As long as the kernel has a flag that is supposed to cause it to
> interpret the partition table, then it should *work* and not silently
> fail. This is a bug in the kernel that should be fixed.
Yes, I don't like the idea with the ioctl workaround in losetup. It's
fine to use such workarounds in stable branches or in distro specific
patches, but I really don't want to use workarounds for bugs in regular
releases (master branch).
Karel
--
Karel Zak <kzak@redhat.com>
http://karelzak.blogspot.com
next prev parent reply other threads:[~2014-12-03 8:36 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-03 9:44 losetup on a image file containing (GPT) partition doesn't create partition devices Francis Moreau
2014-10-03 14:29 ` Dale R. Worley
2014-10-03 19:58 ` Dale R. Worley
2014-10-03 20:26 ` Francis Moreau
2014-10-04 19:35 ` Francis Moreau
2014-10-06 15:47 ` Dale R. Worley
2014-10-06 15:56 ` Francis Moreau
2014-10-27 20:16 ` Mike Frysinger
2014-12-02 19:29 ` Phillip Susi
2014-12-03 8:36 ` Karel Zak [this message]
2014-12-03 14:49 ` Phillip Susi
2014-12-03 16:10 ` Karel Zak
2015-02-16 8:52 ` Mike Frysinger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20141203083617.GD1994@x2.net.home \
--to=kzak@redhat.com \
--cc=francis.moro@gmail.com \
--cc=gabeblack@chromium.org \
--cc=gwendal@chromium.org \
--cc=psusi@ubuntu.com \
--cc=util-linux@vger.kernel.org \
--cc=worley@alum.mit.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.