On 01.08.2012 15:31, Liu Bo wrote: > On 08/01/2012 09:07 PM, Jan Schmidt wrote: >> On Wed, August 01, 2012 at 14:02 (+0200), Liu Bo wrote: >>> On 08/01/2012 07:45 PM, Stefan Behrens wrote: >>>> With commit acce952b0, btrfs was changed to flag the filesystem with >>>> BTRFS_SUPER_FLAG_ERROR and switch to read-only mode after a fatal >>>> error happened like a write I/O errors of all mirrors. >>>> In such situations, on unmount, the superblock is written in >>>> btrfs_error_commit_super(). This is done with the intention to be able >>>> to evaluate the error flag on the next mount. A warning is printed >>>> in this case during the next mount and the log tree is ignored. >>>> >>>> The issue is that it is possible that the superblock points to a root >>>> that was not written (due to write I/O errors). >>>> The result is that the filesystem cannot be mounted. btrfsck also does >>>> not start and all the other btrfs-progs tools fail to start as well. >>>> However, mount -o recovery is working well and does the right things >>>> to recover the filesystem (i.e., don't use the log root, clear the >>>> free space cache and use the next mountable root that is stored in the >>>> root backup array). >>>> >>>> This patch removes the writing of the superblock when >>>> BTRFS_SUPER_FLAG_ERROR is set, and removes the handling of the error >>>> flag in the mount function. >>>> >>> >>> Yes, I have to admit that this can be a serious problem. >>> >>> But we'll need to send the error flag stored in the super block into >>> disk in the future so that the next mount can find it unstable and do >>> fsck by itself maybe. >> >> Hum, that's possible. However, I neither see >> >> a) a safe way to get that flag to disk >> >> nor >> >> b) a situation where this flag would help. When we abort a transaction, we >> just >> roll everything back to the last commit, i.e. a consistent state. So if we >> stop >> writing a potentially corrupt super block, we should be fine anyway. Or am I >> missing something? >> > > I'm just wondering if we can roll everything back well, why do we need fsck?
Mostly for undetected errors. > > thanks, > liubo > >> -Jan >> > > -- > 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 -- 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
