On 3/14/13 9:47 AM, Eric Sandeen wrote: > On 3/14/13 3:56 AM, Anand Jain wrote: >> >> >> On 03/14/2013 12:36 PM, Eric Sandeen wrote: >>> On 3/13/13 10:05 PM, Anand Jain wrote: >>> >>> <maybe a little more commit log would be good?> >>> >>> So here is what confuses me now. :) >>> >>> *every* caller of btrfs_read_dev_super() is now called with >>> 0 for the flags variable, so it never reads the backup >>> under any circumstance. >>> >>> If it's always called w/ 0, what is the point of the argument? >>> Is there another patch you have planned that would use this argument >>> later? >> >> Thanks for the review. yes true. as of now it (BTRFS_SCAN_BACKUP_SB) >> only serves the purpose if in future should we need it. >> purpose is something like a user initiated thread which >> should to go to the backup-SB if primary-SB is not found ?. >> Or I can drop BTRFS_SCAN_BACKUP_SB idea depending on how >> it is convenient as a whole. > > See what others think, perhaps, but if nobody is using it, I think > it should just go away. I'd call it "dead code." :) > > But I am surprised that none of the commands which accept alternate > superblock locations find their way into btrfs_read_dev_super() - > that seems odd to me. Is it re-implemented or open-coded in other > places?
So to be clearer, rather than removing the code right away, maybe it's worth a look to see if the other commands which *want* backup superblocks should be using this same code. Then you'd have a reason for your new flag. :) -Eric > -Eric > > >> Thanks, Anand >> >> -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
