From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steven Whitehouse Date: Tue, 3 Jul 2018 15:34:24 +0100 Subject: [Cluster-devel] [GFS2 PATCH] GFS2: Eliminate bitmap clones In-Reply-To: <1706893656.47709899.1530624526353.JavaMail.zimbra@redhat.com> References: <913319296.47519402.1530554284901.JavaMail.zimbra@redhat.com> <1706893656.47709899.1530624526353.JavaMail.zimbra@redhat.com> Message-ID: List-Id: To: cluster-devel.redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, On 03/07/18 14:28, Bob Peterson wrote: > Hi Steve, > > ----- Original Message ----- >>> Do we really still need "clone bitmaps" in gfs2? If so, why? >>> I think maybe we can get rid of them. Can someone (Steve Whitehouse >>> perhaps?) think of a scenario in which they're still needed? If so, >>> please elaborate and give an example. > (snip) >> You need to ensure that the blocks cannot be reused in the same >> transaction (thats true of all metadata blocks, not just inodes) in >> order that recovery will work correctly. You cannot just eliminate the >> bitmaps without adding a mechanism to prevent this reuse, >> >> Steve. > I don't see how it's possible for a transaction to reuse the same blocks, > even when transactions are combined. Transactions get combined anyway as we batch them up for commit to the journal. The important thing is that we do not have blocks that get used in more than one way (data or metadata) in any one journal transaction. Otherwise when the journal is recovered we cannot figure out what the correct state should be, because we are missing information on the history. So if we decide to find another mechanism to deal with that issue, then thats ok, but the usual caveats about backward compatibility apply of course, so it will not be easy to do. Also, we already have a todo list item to allow transactions to continue in parallel with the journal commit, and we should probably look at that problem first since it is is not easy and we don't want to do anything to make it harder than it needs to be in the mean time, Steve.