Re: Supporting FALLOC_FL_WRITE_ZEROES in NFS4.2 with WRITE_SAME?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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?".

>
> 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
>
>





[Index of Archives]     [Linux Filesystem Development]     [Linux USB Development]     [Linux Media Development]     [Video for Linux]     [Linux NILFS]     [Linux Audio Users]     [Yosemite Info]     [Linux SCSI]

  Powered by Linux