Date: Fri, 16 Nov 2018 18:04:54 +0000 From: bugzilla-noreply@freebsd.org To: fs@FreeBSD.org Subject: [Bug 233245] [UFS] [enhancement] Softupdates fails to track dependency between appended data and i_size Message-ID: <bug-233245-3630-eIJGJm4NMq@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 Conrad Meyer <cem@freebsd.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|[UFS] Softupdates fails to |[UFS] [enhancement] |track dependency between |Softupdates fails to track |appended data and i_size |dependency between appended | |data and i_size --- Comment #5 from Conrad Meyer <cem@freebsd.org> --- Hi Kirk, (In reply to Kirk McKusick from comment #4) > I concur with Kostik on what we are trying to show to the user. Specifica= lly > the filesystem metadata is always correct and we never expose previous > contents of blocks to a user. We have no problem presenting them with zer= oed > 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 di= sk > 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 be= fore > 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 zero= ed > (e.g., a hole in the file) rather than seeing the unwritten data. So, hav= ing > some extra zeros at the end of a file really seems no worse. I fully agree =E2=80=94 the status quo treatment of partial block appends i= s no worse than the overwrite treatment, and that SU does a good job of ensuring the metadata is correct in the face of power failure / crash. What I am propos= ing is definitely an enhancement. I've marked the summary as such to be clear = to anyone who stumbles upon this PR. I filed this in bugzilla to track it as a potential work item for myself, but the discussion that has taken place is useful to me too. > 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 us= eful > than avoiding zeros at the end of files after a crash. I agree. These are more important enhancements to UFS than my proposal. I certainly appreciate the work you are doing and trust you to prioritize the work you think is valuable. I did not expect anyone else to work on this enhancement, so perhaps the freebsd-fs@ "assignee" is bogus. I would be ha= ppy to assign it to myself to take it off the fs@ list, if that seems most reasonable to everybody. > That said, I would be happy to assist you if you want to develop the code= to > extend soft updates to add this semantic. I appreciate the offer =E2=80=94 thank you. > 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 on= ly > works at the end of a file, not when data is added in the middle of a fil= e as > in my example above. Yes, it does seem quite similar to allocdirect (minus the block pointer manipulations, and block-centric i_size math). Do you know of any addition= al good resources I can read for the specific dependency graph behavior / roll= back semantics of SU? I have the FreeBSD D&I 2e book of course, and the source = code is the final word. But if you have any additional references you can share= , I would appreciate it. (Tangential to this enhancement, I might take a pass cleaning up the plain English of the ffs_softdep.c comment blocks. They are thorough, but tend to lack visual separation and thus do not scan easily. Additionally, some references to specific objects are quoted, while others are not. It might = help me understand SU better to do a pass making an attempt to help others understand SU better. :-)) --=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-eIJGJm4NMq>