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=3D233245 --- 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 cont= ents of blocks to a user. We have no problem presenting them with zeroed data wh= ere 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. Suppo= se 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 u= p, 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 zero= s 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 usef= ul 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 da= ta. 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. --=20 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>