On Mon, Jun 05, 2023 at 02:14:44PM -0700, Sarthak Kukreti wrote: > On Sat, Jun 3, 2023 at 8:57 AM Mike Snitzer <snitzer@xxxxxxxxxx> wrote: > > On Fri, Jun 02 2023 at 8:52P -0400, > > Dave Chinner <david@xxxxxxxxxxxxx> wrote: > > > On Fri, Jun 02, 2023 at 11:44:27AM -0700, Sarthak Kukreti wrote: > > > > > The only way to distinquish the caller (between on-behalf of user data > > > > > vs XFS metadata) would be REQ_META? > > > > > > > > > > So should dm-thinp have a REQ_META-based distinction? Or just treat > > > > > all REQ_OP_PROVISION the same? > > > > > > > > > I'm in favor of a REQ_META-based distinction. > > > > > > Why? What *requirement* is driving the need for this distinction? > > > > Think I answered that above, XFS delalloc accounting parity on thinp. > > > I actually had a few different use-cases in mind (apart from the user > data provisioning 'fear' that you pointed out): in essence, there are > cases where userspace would benefit from having more control over how > much space a snapshot takes: > > 1) In the original RFC patchset [1], I alluded to this being a > mechanism for pre-allocating space for preserving space for thin > logical volumes. The use-case I'd like to explore is delta updatable > read-only filesystems similar to systemd system extensions [2]: In > essence: > a) Preserve space for a 'base' thin logical volume that will contain a > read-only filesystem on over-the-air installation: for filesystems > like squashfs and erofs, pretty much the entire image is a compressed > file that I'd like to reserve space for before installation. > b) Before update, create a thin snapshot and preserve enough space to > ensure that a delta update will succeed (eg. block level diff of the > base image). Then, the update is guaranteed to have disk space to > succeed (similar to the A-B update guarantees on ChromeOS). On > success, we merge the snapshot and reserve an update snapshot for the > next possible update. On failure, we drop the snapshot. Sounds very similar to the functionality blksnap is supposed to provide.... https://lore.kernel.org/linux-fsdevel/20230404140835.25166-1-sergei.shtepa@xxxxxxxxx/ > 2) The other idea I wanted to explore was rollback protection for > stateful filesystem features: in essence, if an update from kernel 4.x > to 5.y failed very quickly (due to unrelated reasons) and we enabled > some stateful filesystem features that are only supported on 5.y, we'd > be able to rollback to 4.x if we used short-lived snapshots (in the > ChromiumOS world, the lifetime of these snapshots would be < 10s per > boot). Not sure that blksnap has a "roll origin back to read-only snapshot" feature yet, but that's what you'd need for this. i.e. on success, drop the snapshot. On failure, "roll origin back to snapshot and reboot". Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx -- dm-devel mailing list dm-devel@xxxxxxxxxx https://listman.redhat.com/mailman/listinfo/dm-devel
