`  == Superblocks ==  The Superblocks section claims ``Superblock mirrors are kept at fixed locations:[77] 64 KiB into every block device, with additional copies at 64 MiB, 256 GiB and 1 PiB. When a superblock mirror is updated, its generation number is incremented. At mount time, the copy with the highest generation number is used. All superblock mirrors are updated in tandem, except in SSD mode which alternates updates among mirrors to provide some wear levelling.``  And (https://btrfs.wiki.kernel.org/index.php/User:Wtachi/On-disk_Format#Superblock) claims ``Note that btrfs only recognizes disks with a valid 0x1 0000 superblock; otherwise, there would be confusion with other filesystems. ``  I haven't seen any relevant information in (http://btrfs.ipv5.de/) indicating anything about the current state of superblock use.  In old link - now seemingly defunct but still cached by Google - (https://oss.oracle.com/pipermail/btrfs-devel/2008-February/000513.html), Chris Mason writes that:  Yes, SSDs are a big target of mine, and so the parts that are not currently favorable for SSDs will be changed.  The big problem right now is that btrfs writes to a fixed super block for every commit.  That will change to a rotating set of fixed super blocks to lower wear and improve redundancy.   * Is there any information if btrfs still hammers the same fixed superblock locations? * Is there any information about the implications that a broken primary superblock will make btrfs no longer recognize the disk, implying that this single (but constantly updated) data structure is a single-point-of-failure? * Is there any information about the implications for SSD wear leveling if no change has been introduced? And especially how common is it that the SSD uses region-based wear leveling in which each superblock will only rotate among a limited number of flash blocks of the SSD? Or where the two first superblocks might even end up in the same wear-leveling region?   `