lkml.org 
[lkml]   [2023]   [Oct]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [PATCH v8 3/5] loop: Add support for provision requests
    On Sun, Oct 8, 2023 at 4:37 PM Dave Chinner <david@fromorbit.com> wrote:
    >
    > On Fri, Oct 06, 2023 at 06:28:15PM -0700, Sarthak Kukreti wrote:
    > > Add support for provision requests to loopback devices.
    > > Loop devices will configure provision support based on
    > > whether the underlying block device/file can support
    > > the provision request and upon receiving a provision bio,
    > > will map it to the backing device/storage. For loop devices
    > > over files, a REQ_OP_PROVISION request will translate to
    > > an fallocate mode 0 call on the backing file.
    > >
    > > Signed-off-by: Sarthak Kukreti <sarthakkukreti@chromium.org>
    > > Signed-off-by: Mike Snitzer <snitzer@kernel.org>
    >
    >
    > Hmmmm.
    >
    > This doesn't actually implement the required semantics of
    > REQ_PROVISION. Yes, it passes the command to the filesystem
    > fallocate() implementation, but fallocate() at the filesystem level
    > does not have the same semantics as REQ_PROVISION.
    >
    > i.e. at the filesystem level, fallocate() only guarantees the next
    > write to the provisioned range will succeed without ENOSPC, it does
    > not guarantee *every* write to the range will succeed without
    > ENOSPC. If someone clones the loop file while it is in use (i.e.
    > snapshots it via cp --reflink) then all guarantees that the next
    > write to a provisioned LBA range will succeed without ENOSPC are
    > voided.
    >
    > So while this will work for basic testing that the filesystem is
    > issuing REQ_PROVISION based IO correctly, it can't actually be used
    > for hosting production filesystems that need full REQ_PROVISION
    > guarantees when the loop device backing file is independently
    > shapshotted via FICLONE....
    >
    > At minimuim, this set of implementation constraints needs tobe
    > documented somewhere...
    >
    Fair point. I wanted to have a separate fallocate() mode
    (FALLOC_FL_PROVISION) in the earlier series of the patchset so that we
    can distinguish between a provision request and a regular fallocate()
    call; I dropped it from the series after feedback that the default
    case should suffice. But this might be one of the cases where we need
    an explicit intent that we want to provision space.

    Given a separate FALLOC_FL_PROVISION mode in the scenario you
    mentioned, the filesystem could copy previously 'provisioned' blocks
    to new blocks (which implicitly provisions them) or reserve blocks for
    use (and passing through REQ_OP_PROVISION below). That also means that
    the filesystem should track 'provisioned' blocks and take appropriate
    actions to ensure the provisioning guarantees.

    For filesystems without copy-on-write semantics (eg. ext4),
    REQ_OP_PROVISION should still be equivalent to mode == 0.

    For now, I'll add the details to the commit message and the loop
    driver code (side note: should there be device documentation on the
    loop device driver?). WDYT?

    Best
    Sarthak

    > -Dave.
    > --
    > Dave Chinner
    > david@fromorbit.com

    \
     
     \ /
      Last update: 2023-10-11 00:43    [W:6.803 / U:0.012 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site