On Tue, Mar 18, 2025 at 4:54 PM Trond Myklebust <trondmy@xxxxxxxxxxxxxxx> wrote: > > On Tue, 2025-03-18 at 16:01 -0700, Rick Macklem wrote: > > On Tue, Mar 18, 2025 at 2:17 PM Trond Myklebust > > <trondmy@xxxxxxxxxxxxxxx> wrote: > > > > > > On Tue, 2025-03-18 at 14:03 -0700, Rick Macklem wrote: > > > > > > > > The problem I see is that WRITE_SAME isn't defined in a way where > > > > the > > > > NFSv4 server can only implement zero'ng and fail the rest. > > > > As such. I am thinking that a new operation for NFSv4.2 that does > > > > writing > > > > of zeros might be preferable to trying to (mis)use WROTE_SAME. > > > > > > Why wouldn't you just implement DEALLOCATE? > > Not my area of expertise, but I believe some like to know that > > zeros have overwritten the data instead of the data just being > > unallocated > > (blocks still sitting around with the data in it). > > How do you guarantee that? There could be file or filesystem level > snapshots, there is the drive's own FTL... snapshits are definitely a big security risk. As I just posted, I do\ not know what guarantees the NVME Wr_zero command provides? > > There are good reasons why there are companies that specialise in > physical destruction of storage media. When at Guelph, we used the 5lb hammer method. Good enough for a university environment. (For some reason, I always enjoyed smashing hardware to bits.;;-) rick > > -- > Trond Myklebust > Linux NFS client maintainer, Hammerspace > trond.myklebust@xxxxxxxxxxxxxxx > >
