On Wed, 01 Aug 2012 16:31:54 +0200, Stefan Behrens wrote: > On Wed, 01 Aug 2012 21:31:58 +0800, 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? > > If the disks support barriers, we roll everything back very well. The > most recent superblock on the disks always defines a consistent > filesystem state. There are only two remaining filesystem consistency > issues left that can cause inconsistent states, one is the one that the > patch in this email addresses, and the second one is that the error > result from barrier_all_devices() is ignored (which I want to change next). Hi Liu Bo, Do you have any remaining objections to that patch? -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
