Date: Fri, 16 Nov 2018 02:58: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-Pg25tQUTQ1@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 #2 from Conrad Meyer <cem@freebsd.org> --- Hi Kirk, Thanks for your prompt reply. (In reply to Kirk McKusick from comment #1) > As you note, soft updates does not currently consider it necessary to ens= ure > that the new contents of the block be written before increasing the file = size > if it knows that the exposed contents will be zero (as opposed to the ran= dom > data that was in a previously used block where it does ensure that the bl= ock is > written before it can be accessed). Yep, understood. > It would be possible to add a requirement that the new data be written be= fore > the size could be updated, That is the proposal. :-) > but it is not clear to me that adding this extra overhead is worthwhile. Overhead in which sense? I can imagine a few objections (it makes the code more complicated; there is some minor additional memory burden; SU dependen= cy graphs get a little deeper) but maybe you have others in mind I hadn't thou= ght of. I don't think there is any additional IO cost (perhaps longer fsync ti= me on appended files due to the additional ordering barrier?), but I might wel= l be missing something. As far as whether any runtime overhead is worthwhile, I think there are two relevant dimensions. One, what is the measurable overhead, if any? (We ca= n't really answer this one until we have a proof of concept implementation.) A= nd two, what is the user willing to accept, both in terms of overhead and appe= nd data fidelity? I think it's likely a trade-off we might not want to make unilaterally, but instead leave to the end user. It should be pretty easy to add it as a mount option or something like that= ; in the same vein as "noatime" allows users to disable a feature with too much overhead. I don't see any significant barriers to enabling or disabling it on-the-fly for existing mounts at runtime, either. > Also, this case includes overwriting data in the middle of an earlier blo= ck in the file for which there is nothing that we can do. Understood =E2=80=94 append is /the/ special case of write where this is po= ssible. But it is also a fairly common case, and given that we can do it safely, I thin= k we should aim to do it safely. (For middle-of-file partial overwrites, we could order data block flushing = with inode mtime update, if we do not already. That would be a pretty minimal protection and would not save us from torn writes. I think we might also be able to allocate data blocks out-of-place and order full block writes with their corresponding block pointer or indirect block pointer updates, but th= at has significant downsides, such as file fragmentation, and isn't something = I'm interested in right now.) > Note that you cannot put the test into ffs_write() in the way that you ha= ve > done (which makes the call for any growth in size). It can only be done w= hen > the growth is such that it does not go out of an existing block allocatio= n or > is overwriting an earlier part of the file. The elided portion of ffs_write() between lines 756 and 781 invokes UFS_BALLOC() to allocate any blocks needed -- so I believe the suggested location in ffs_write() would be within an existing block allocation. But maybe I am mistaken. I am not attached to the location, it just seemed lik= e a plausible spot to me. (There is a smaller separate concern, which is that any full block append is already fully tracked with allocdirect or allocindirect =E2=80=94 we only w= ant the proposed partial append dependency for the last iteration of the loop in ffs_write.) --=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-Pg25tQUTQ1>