On Tue, Jan 7, 2025 at 4:10 PM Anna Schumaker <anna.schumaker@xxxxxxxxxx> wrote: > > Hi Takeshi, > > On 1/6/25 6:56 PM, Takeshi Nishimura wrote: > > Dear list, > > > > how can we get ADB (WRITE_SAME) support in (Debian) Linux nfsd, and an > > ioct() in Linux nfsd client to use it? > > Thanks for the request! Just so you're aware of the process, this email list is for upstream Linux kernel development. If we decide to go ahead with adding WRITE_SAME support it'll be up to Debian later to enable it (that part is out of our hands, and isn't up to us). I assume WRITE_SAME will not have a separate build flag, right? > > > > > We have a set of custom "big data" applications which could greatly > > benefit from such an acceleration ABI, both for implementing "zero > > data" (fill blocks with 0 bytes), and fill blocks with identical data > > patterns, without sending the same pattern over and over again over > > the network wire. > > Having said that, I'm not opposed to implementing WRITE_SAME. I wonder if we could somehow use it to build support for fallocate's FALLOC_FL_ZERO_RANGE flag at the same time. No, I am asking really for WRITE_SAME support to write identical data to multiple locations. Like https://linux.die.net/man/8/sg_write_same Writing zero bytes is just a subset, and not what we need. WRITE_SAME is intended as "big data" and database accelerator function. > > I'm also wondering if there would be any advantage to local filesystems if this were to be implemented as a generic system call, rather than as an NFS-specific ioctl(), since some storage devices have a WRITE_SAME operation that could be used for acceleration. But I haven't convinced myself either way yet. Getting a new, generic syscall in Linux takes 3-5 years on average. By then our project will be finished, or renewed with new funding, but all without getting a boost from WRITE_SAME support in NFS- -- Internationalization&localization dev / 大阪大学 Takeshi Nishimura <takeshi.nishimura.linux@xxxxxxxxx>
