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? -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
