From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from aserp2130.oracle.com ([141.146.126.79]:55586 "EHLO aserp2130.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751124AbeCZXsn (ORCPT ); Mon, 26 Mar 2018 19:48:43 -0400 Subject: Re: [PATCH] btrfs-progs: wipe copies of the stale superblock beyond -b size To: Nikolay Borisov , linux-btrfs@vger.kernel.org From: Anand Jain Message-ID: Date: Tue, 27 Mar 2018 07:50:33 +0800 MIME-Version: 1.0 In-Reply-To: <142e5830-3692-ddac-81d9-c29448969c63@suse.com> Content-Type: text/plain; charset=utf-8; format=flowed Sender: linux-btrfs-owner@vger.kernel.org List-ID: References: <20180326082742.9235-10-anand.jain@oracle.com> <142e5830-3692-ddac-81d9-c29448969c63@suse.com> > I told you this code can be made a lot simpler, simply by modifying the > last argument passed to zero_dev_clamped. I even posted the resulting > diff which was just 3 lines changed. > > I agree that it's a good idea to wipe all available superblock when we > use -b. However I don't agree with your approach - it adds a loop, it > adds a bunch of checks and makes the complexity orders of magnitude > higher than it could be. So I'm asking again - is there any inherent > benefit which I'm missing in your newly added 35 lines of code against > just passing the block device to zero_dev_clamped and letting the > existing logic take care of everything? I had that idea for v1 as well, but I didn't do it because it would zero bytenr_copy#2 even when there is no btrfs superblock, (which is fine only with in block_count). Some might view it as corrupting the usr data (for which they have specified -b option?)? I am just discussing I don't have any usecase to prove it though. Do you have any idea? If you think it should be ok, I shall go ahead and zero without checking for the btrfs superblock beyond block_count. Thanks, Anand