On Wed, Jun 14, 2023 at 08:25:15AM +1000, Dave Chinner wrote: > > + * Return: 0 if succeeded, negative errno otherwise. > > + */ > > +#define IOCTL_BLKSNAP_SNAPSHOT_APPEND_STORAGE \ > > + _IOW(BLKSNAP, blksnap_ioctl_snapshot_append_storage, \ > > + struct blksnap_snapshot_append_storage) > > That's an API I'm extremely uncomfortable with. We've learnt the > lesson *many times* that userspace physical mappings of underlying > file storage are unreliable. > > i.e. This is reliant on userspace telling the kernel the physical > mapping of the filesystem file to block device LBA space and then > providing a guarantee (somehow) that the mapping will always remain > unchanged. i.e. It's reliant on passing FIEMAP data from the > filesystem to userspace and then back into the kernel without it > becoming stale and somehow providing a guarantee that nothing (not > even the filesystem doing internal garbage collection) will change > it. Hmm, I never thought of this API as used on files that somewhere had a logical to physical mapping applied to them. Sergey, is that the indtended use case? If so we really should be going through the file system using direct I/O.
