On 27.03.2018 02:50, Anand Jain wrote: > > >> 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. Right, so the pertinent question is - is anyone expecting to do mkfs on a volume irrespective of the options and expect to be able to recover data prior to the mkfs? I think the answer is 'no', but let's see what the community says. > > Thanks, Anand > -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
