Date: Fri, 16 Nov 2018 09:25:11 +0000 From: bugzilla-noreply@freebsd.org To: fs@FreeBSD.org Subject: [Bug 233245] [UFS] Softupdates fails to track dependency between appended data and i_size Message-ID: <bug-233245-3630-HSJBJpdYIg@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-233245-3630@https.bugs.freebsd.org/bugzilla/> References: <bug-233245-3630@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=233245 --- Comment #4 from Kirk McKusick <mckusick@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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-233245-3630-HSJBJpdYIg>