[Bug 233245] [UFS] Softupdates fails to track dependency between appended data and i_size

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=233245

--- Comment #4 from Kirk McKusick <mckusick at FreeBSD.org> ---
I concur with Kostik on what we are trying to show to the user. Specifically
the filesystem metadata is always correct and we never expose previous contents
of blocks to a user. We have no problem presenting them with zeroed data where
we do not have properly written data available. Consider that the user has a
large file that has a hole at logical blocks 1, 2, and 3. Now suppose the
application fills in this hole by writing logical blocks 1, 2, and 3. Suppose
the kernel has managed to get blocks 1 and 3 written to disk but not block 2
when the inode gets written. Here we `roll back' the inode putting a hole in
the file at block 2, then put the block pointer back before we unlock it and
allow it to be viewed by a read operation. So as long as the system stays up,
the applications always see all the written data. But if the system crashes,
then when it comes back up block 2 will read back as zeroed (e.g., a hole in
the file) rather than seeing the unwritten data. So, having some extra zeros at
the end of a file really seems no worse.

I am presently working on hardening the filesystem. Putting check-hashes on the
metadata, and working to handle disk failures by forcibly unmounting the
filesystem rather than having the kernel panic. I think these are more useful
than avoiding zeros at the end of files after a crash. That said, I would be
happy to assist you if you want to develop the code to extend soft updates to
add this semantic. You would need to add a new dependency type (or possibly
extend allocdirect) to track when an existing block is extended with new data.
When the inode is written, you need to roll back the length to the old size,
then restore the length when the write completes. This of course only works at
the end of a file, not when data is added in the middle of a file as in my
example above.

-- 
You are receiving this mail because:
You are the assignee for the bug.