Date: Tue, 13 Nov 2018 15:08:51 -0800 From: Conrad Meyer <cem@freebsd.org> To: Alan Somers <asomers@freebsd.org> Cc: "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org>, freebsd-fs <freebsd-fs@freebsd.org>, freebsd-current <freebsd-current@freebsd.org> Subject: Re: Hole-punching, TRIM, etc Message-ID: <CAG6CVpU8qksCRCJQoJEVsoCb07cTq9sMmbkKDVJmRcLxaqzhGQ@mail.gmail.com> In-Reply-To: <CAOtMX2g6TFMrunOgMoG5Wt%2BL3U6z_BAPF7SrM%2BTczQS9gwX1hQ@mail.gmail.com> References: <CAOtMX2jgb_Pf9-MqirM=xihVpyRmAGZKx2VRnvA_1Fx6kMYXXg@mail.gmail.com> <CAG6CVpVcr=e=Dmg3JKD0BVQ9wiEWUujThAwy=PXyoyoRr_R7Og@mail.gmail.com> <CAOtMX2g6TFMrunOgMoG5Wt%2BL3U6z_BAPF7SrM%2BTczQS9gwX1hQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Nov 13, 2018 at 2:59 PM Alan Somers <asomers@freebsd.org> wrote: > > On Tue, Nov 13, 2018 at 3:51 PM Conrad Meyer <cem@freebsd.org> wrote: >> >> On Tue, Nov 13, 2018 at 2:10 PM Alan Somers <asomers@freebsd.org> wrote: >> > ... >> > 8) Add aio_freesp(2), an asynchronous version of fcntl(F_FREESP). >> >> Why not just add DIOCGDELETE support to various VOP_IOCTL >> implementations? The file objects forward correctly through vn_ioctl >> to VOP_IOCTL for both regular files and devfs VCHR nodes. >> >> We can emulate the Linux API if we want to be compatible there, but I >> wouldn't bother with Solaris. > > The only reason that I prefer the Solaris API is because it doesn't requi= re adding another syscall, and because Linux's fallocate(2) does a whole bu= nch of other things besides hole-punching. I am imagining that if we went this route, we would implement Linux fallocate as a library shim around the native FreeBSD ioctl (or whatever) rather than an independent system call. This would be for API compatibility, not ABI compatibility. But Linux compat can be set aside for now, I think =E2=80=94 it's a secondary concern. > What about an asynchronous version? ioctl(2) is still synchronous. Do y= ou see any better way to hole-punch/TRIM asynchronously than with aio? Yeah, this is a good consideration. No, I don't have any better suggestion for an asynchronous API. In general our VOPs tend to be synchronous. Aio does seem like the logical home for a new asynchronous API. Best regards, Conrad
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAG6CVpU8qksCRCJQoJEVsoCb07cTq9sMmbkKDVJmRcLxaqzhGQ>