On 2019/3/11 下午8:26, Nikolay Borisov wrote: > > > On 11.03.19 г. 3:17 ч., Qu Wenruo wrote: >> >> >> On 2019/3/11 上午7:09, Chris Murphy wrote: >>> In the case where superblock 0 at 65536 is valid but stale (older than >>> the others): >> >> Then this means either the fs is fuzzed, or the FUA implementation of >> the disk is completely screwed up. >> >> Btrfs kernel submit super blocks as the following sequence: >> 1) wait all metadata write >> 2) flush >> 3) FUA the primary superblock > > SATA devices generally do not have FUA support. For example my evo 850 > ssds do not support it nor does my evo 860 PRO. IMO not having > functioning FUA seems to be the norm rather than an exception. Kernel block layer will translate FUA to write + flush. So in that case we will do: 1) wait all metadata write 2) flush 3) write first sb, flush 4) write backup sb For FUA -> write + flush, it's less atomic than native FUA, but it should be good enough for pseudo-atomic. Thanks, Qu > > >> 4) write the backup superblocks >> >> If backup is newer than primary, then the FUA write doesn't reach disk >> before normal write. >> This means any fs could be corrupted on that disk, not only btrfs. >> >>> >>> 1. btrfs check doesn't complain, the stale super is used for the check >>> 2. when mounting, super 0 is used, no complaints at mount time, fairly >>> quickly the newer supers are overwritten >> >> The reason why kernel doesn't search backup roots is to avoid stale btrfs. >> For case like mkfs.btrfs -> do btrfs write -> mkfs.xfs -> try mount as >> btrfs again, this would cause problems. >> >> So IMHO always use the primary superblock is the designed behavior. >> >> Thanks, >> Qu >> >>> >>> Is this expected? In particular, in lieu of `btrfs rescue super` >>> behavior which considers super 0 a bad super, and offers to fix it >>> from the newer ones, and when I answer y, it replaces super 0 with >>> newer information from the other supers. >>> >>> I think the `btrfs rescue` behavior is correct. I would expect that >>> all the supers are read at mount time, and if there's discrepancy that >>> either there's code to suspiciously sanity check the latest roots in >>> the newest super, or it flat out fails to mount. Mounting based on >>> stale super data seems risky doesn't it? >>> >>
