On Fri, Aug 20, 2021 at 05:35:21PM +0800, Chao Yu wrote: > > > > > > > > > > Hmm, I'm still trying to deal with this as a corner case where the > > > > > writes > > > > > haven't completed due to an error. How about keeping the preallocated > > > > > block > > > > > offsets and releasing them if we get an error? Do we need to handle > > > > > EIO right? > > > > > > > > What about the case that CP + SPO following DIO preallocation? User will > > > > encounter uninitialized block after recovery. > > > > > > I think buffered writes as a workaround can expose the last unwritten > > > block as > > > well, if SPO happens right after block allocation. We may need to > > > compromise > > > at certain level? > > > > > > > Freeing preallocated blocks on error would be better than nothing, although > > note > > that the preallocated blocks may have filled an arbitrary sequence of holes > > -- > > so simply truncating past EOF would *not* be sufficient. > > > > But really filesystems need to be designed to never expose uninitialized > > data, > > even if I/O errors or a sudden power failure occurs. It is unfortunate that > > f2fs apparently wasn't designed with that goal in mind. > > > > In any case, I don't think we can proceed with any other f2fs direct I/O > > improvements until this data leakage bug can be solved one way or another. > > If > > my patch to remove support for allocating writes isn't acceptable and the > > desired solution is going to require some more invasive f2fs surgery, are > > you or > > Chao going to work on it? I'm not sure there's much I can do here. > > I may have time to take look into the implementation as I proposed above, > maybe > just enabling this in FSYNC_MODE_STRICT mode if user concerns unwritten data? > thoughts? >
What does this have to do with fsync? - Eric _______________________________________________ Linux-f2fs-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
