From owner-freebsd-fs@freebsd.org Fri Nov 16 09:25:14 2018 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 505F6112D00F for ; Fri, 16 Nov 2018 09:25:14 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id C48C377F07 for ; Fri, 16 Nov 2018 09:25:13 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 89264112D00E; Fri, 16 Nov 2018 09:25:13 +0000 (UTC) Delivered-To: fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 67421112D00D for ; Fri, 16 Nov 2018 09:25:13 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E094577EFD for ; Fri, 16 Nov 2018 09:25:12 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 047A5652D for ; Fri, 16 Nov 2018 09:25:12 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id wAG9PBxG055128 for ; Fri, 16 Nov 2018 09:25:11 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id wAG9PBYT055119 for fs@FreeBSD.org; Fri, 16 Nov 2018 09:25:11 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: fs@FreeBSD.org Subject: [Bug 233245] [UFS] Softupdates fails to track dependency between appended data and i_size Date: Fri, 16 Nov 2018 09:25:11 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: mckusick@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: fs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-Rspamd-Queue-Id: C48C377F07 X-Spamd-Result: default: False [-105.92 / 40.00]; FORGED_RECIPIENTS_FORWARDING(0.00)[]; ALLOW_DOMAIN_WHITELIST(-100.00)[freebsd.org]; FORWARDED(0.00)[fs@mailman.ysv.freebsd.org]; SPF_FAIL_FORWARDING(0.00)[]; TO_DN_NONE(0.00)[]; HAS_XAW(0.00)[]; R_SPF_SOFTFAIL(0.00)[~all]; XAW_SERVICE_ACCT(1.00)[]; RCVD_IN_DNSWL_MED(-0.20)[5.0.0.0.0.5.0.0.0.0.0.0.0.0.0.0.a.6.0.2.4.5.2.2.0.0.9.1.1.0.0.2.list.dnswl.org : 127.0.9.2]; MX_GOOD(-0.01)[cached: mx66.freebsd.org]; NEURAL_HAM_SHORT(-1.00)[-0.998,0]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; IP_SCORE(-3.71)[ip: (-9.87), ipnet: 2001:1900:2254::/48(-4.82), asn: 10310(-3.76), country: US(-0.10)]; ASN(0.00)[asn:10310, ipnet:2001:1900:2254::/48, country:US]; FORGED_RECIPIENTS(0.00)[fs@FreeBSD.org,freebsd-fs@freebsd.org]; TO_DOM_EQ_FROM_DOM(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; FROM_NO_DN(0.00)[]; RCVD_COUNT_SEVEN(0.00)[7] X-Rspamd-Server: mx1.freebsd.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2018 09:25:14 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D233245 --- Comment #4 from Kirk McKusick --- 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.=