All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gwendal Grignou <gwendal@chromium.org>
To: evgreen@chromium.org
Cc: bvanassche@acm.org, axboe@kernel.dk, asavery@chromium.org,
	linux-block@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/2] loop: Better discard for block devices
Date: Thu, 1 Nov 2018 15:41:10 -0700	[thread overview]
Message-ID: <CAPUE2usCoYN7udO8eH7TWE2KGXoJF4O2ZV=wokL7=yC6RwQf8g@mail.gmail.com> (raw)
In-Reply-To: <CAE=gft4xwXuJ=aHbF08SxFxtSRX_6KBzPHxCCMbA6F7RnGQ8jA@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1887 bytes --]

On Thu, Nov 1, 2018 at 11:15 AM Evan Green <evgreen@chromium.org> wrote:

> On Tue, Oct 30, 2018 at 4:50 PM Bart Van Assche <bvanassche@acm.org>
> wrote:
> >
> > On Tue, 2018-10-30 at 16:06 -0700, Evan Green wrote:
> > > This series addresses some errors seen when using the loop
> > > device directly backed by a block device. The first change plumbs
> > > out the correct error message, and the second change prevents the
> > > error from occurring in many cases.
> >
> > Hi Evan,
> >
> > Can you provide some information about the use case? Why do you think
> that
> > it would be useful to support backing a loop device by a block device?
> Why
> > to use the loop driver instead of dm-linear for this use case?
> >
>
> Hi Bart,
> In our case, the Chrome OS installer uses the loop device to map
> slices of the disk that will ultimately represent partitions [1]. I
> believe it has been doing install this way for a very long time, and
> has been working well. It actually continues to work, but on block
> devices that don't support discard operations, things are a tiny bit
> bumpy. This series is meant to smooth out those bumps. As far as I
> knew this was a supported scenario.
>
> -Evan
> [1]
> https://chromium.googlesource.com/chromiumos/platform/installer/+/master/chromeos-install



The code has moved to
https://chromium.googlesource.com/chromiumos/platform2/+/master/installer/chromeos-install
but the idea is the same. We create a loop device to abstract the
persistent destination. The destination can be a block device or a file.
The later case is used for creating master images to be flashed on memory
chip before soldering on the production line.
It is handy when the final device is 4K block aligned but the builder is
using 512b block aligned device, we can mount a device over a file that
will behave like the real device we will flash the image on.

Gwendal.

[-- Attachment #2: Type: text/html, Size: 2712 bytes --]

  reply	other threads:[~2018-11-01 22:41 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-30 23:06 [PATCH 0/2] loop: Better discard for block devices Evan Green
2018-10-30 23:06 ` [PATCH 1/2] loop: Report EOPNOTSUPP properly Evan Green
2018-11-28  1:06   ` Ming Lei
2018-10-30 23:06 ` [PATCH 2/2] loop: Better discard support for block devices Evan Green
2018-11-26 18:53   ` Evan Green
2018-11-27  2:55     ` Ming Lei
2018-11-27 23:34       ` Evan Green
2018-11-28  1:28         ` Ming Lei
2018-11-28  1:26   ` Ming Lei
2018-12-04 22:19     ` Evan Green
2018-12-05  1:10       ` Ming Lei
2018-12-05 19:35         ` Evan Green
2018-12-06  0:22           ` Ming Lei
2018-12-06  3:15           ` Martin K. Petersen
2018-12-10 17:31             ` Evan Green
2018-12-18 23:48               ` Evan Green
2018-10-30 23:50 ` [PATCH 0/2] loop: Better discard " Bart Van Assche
2018-10-30 23:50   ` Bart Van Assche
2018-11-01 18:15   ` Evan Green
2018-11-01 22:41     ` Gwendal Grignou [this message]
2018-11-01 22:44     ` Gwendal Grignou
2018-11-02 16:02       ` Bart Van Assche
2018-11-05 20:35         ` Evan Green

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='CAPUE2usCoYN7udO8eH7TWE2KGXoJF4O2ZV=wokL7=yC6RwQf8g@mail.gmail.com' \
    --to=gwendal@chromium.org \
    --cc=asavery@chromium.org \
    --cc=axboe@kernel.dk \
    --cc=bvanassche@acm.org \
    --cc=evgreen@chromium.org \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /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.