On Tue, 2025-03-18 at 18:40 -0700, Rick Macklem wrote: > On Tue, Mar 18, 2025 at 6:12 PM Trond Myklebust > <trondmy@xxxxxxxxxxxxxxx> wrote: > > > > On Tue, 2025-03-18 at 23:59 +0000, Trond Myklebust wrote: > > > On Tue, 2025-03-18 at 16:52 -0700, Rick Macklem wrote: > > > > On Tue, Mar 18, 2025 at 4:40 PM Trond Myklebust > > > > <trondmy@xxxxxxxxxxxxxxx> wrote: > > > > > > > > > Yes, I also realise that none of the above operations > > > > > actually > > > > > resulted > > > > > in blocks being physically filled with data, but all modern > > > > > flash > > > > > based > > > > > drives tend to have a log structured FTL. So while > > > > > overwriting > > > > > data > > > > > in > > > > > the HDD era meant that you would usually (unless you had a > > > > > log > > > > > based > > > > > filesystem) overwrite the same physical space with data, > > > > > today's > > > > > drives > > > > > are free to shift the rewritten block to any new physical > > > > > location > > > > > in > > > > > order to ensure even wear levelling of the SSD. > > > > Yea. The Wr_zero operation writes 0s to the logical block. Does > > > > that > > > > guarantee there is no "old block for the logical block" that > > > > still > > > > holds > > > > the data? (It does say Wr_zero can be used for secure erasure, > > > > but??) > > > > > > > > Good question for which I don't have any idea what the answer > > > > is, > > > > rick > > > > > > In both the above arguments, you are talking about specific > > > filesystem > > > implementation details that you'll also have to address with your > > > new > > > operation. > > > > Actually, let me correct that... I'm not aware of any requirement > > on > > any of the NFSv4.2 operations or the NFSv4.2 extensions, that > > expect > > the permanent and irrevocable deletion of data. > > I definitely won't say there isn't a use case for it, but I am > > saying > > that it isn't covered by any NFS protocol today. > Agreed. > > I thought it was an implementation of FALLOC_FL_ZERO_RANGE > was what was being looked at (or is there now a separate > FALLOC_FL_WRITE_ZEROS?). I agree that the NFSV4.2 > DEALLOCATE followed by ALLOCATE seems to satisfy the > requirement. > There is the question "What happens if DEALLOCATE > succeeds and then ALLOCATE fails?". Not an issue that is covered by WRITE_SAME either. The latter is not guaranteed to be atomic, so it is perfectly possible for you to find half your data gone, and the rest intact. Oddwise, you're actually better off with DEALLOCATE+ALLOCATE because you do actually get a second chance to successfully write the data even if the ALLOCATE failed. So none of the above objections are fully covered by any of the existing NFSv4.2 operations. Your mission, should you accept, is to describe in full to the IETF working group, the use cases for all of the above requirements. This email will self-destruct... > > > > IOW: if data wiping is what you're actually looking for here, then > > I > > think that needs to be a new operation, and we'll need a lot of > > discussion about how the NFS protocol should deal with all the > > various > > ways in which not just the storage, but also the filesystem go > > about > > trying to preserve data. We can probably leave the existence of > > external backups as an exercise for the user... 🤔️ > > > > -- > > Trond Myklebust > > Linux NFS client maintainer, Hammerspace > > trond.myklebust@xxxxxxxxxxxxxxx > > > > > -- Trond Myklebust Linux NFS client maintainer, Hammerspace trond.myklebust@xxxxxxxxxxxxxxx
