[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZIldkb1pwhNsSlfl@infradead.org>
Date: Tue, 13 Jun 2023 23:26:25 -0700
From: Christoph Hellwig <hch@...radead.org>
To: Dave Chinner <david@...morbit.com>
Cc: Sergei Shtepa <sergei.shtepa@...am.com>, axboe@...nel.dk,
hch@...radead.org, corbet@....net, snitzer@...nel.org,
viro@...iv.linux.org.uk, brauner@...nel.org, dchinner@...hat.com,
willy@...radead.org, dlemoal@...nel.org, linux@...ssschuh.net,
jack@...e.cz, ming.lei@...hat.com, linux-block@...r.kernel.org,
linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-fsdevel@...r.kernel.org, Donald Buczek <buczek@...gen.mpg.de>
Subject: Re: [PATCH v5 04/11] blksnap: header file of the module interface
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.
Powered by blists - more mailing lists