Hi, chris, Is there any comment on this "Forced readonly mounts on errors" patchset? thanks, Liu Bo On 12/03/2010 04:15 PM, liubo wrote: > Btrfs has a number of BUG_ON()s, which may lead btrfs to unpleasant panic. > Meanwhile, they are very ugly and should be handled more propriately. > > There are mainly two ways to deal with these BUG_ON()s. > > 1. For those errors which can be handled well by callers, we just return their > error number to callers. > > 2. For others, We can force the filesystem readonly when it hits errors, which > is what this patchset has done. Replaced BUG_ON() with the interface provided > in this patchset, we will get error infomation via dmesg. Since btrfs is now > readonly, we can save our data safely and umount it, then a btrfsck is > recommended. > > By these ways, we can protect our filesystem from panic caused by those > BUG_ONs. > > We still need a incompat flag to make old kernels happy. > > This patchset needs more test. > > v2->v3: > - since btrfs may do log replay after crash, even it is mounted as readonly, > and we have add a readonly check at start transaction time, it needs to set > and to restore readonly flags around log replay. > > v1->v2: > - in order to avoid deadlock thing, move write super stuff from error handle > path to unmount time. > - remove BTRFS_SUPER_FLAG_VALID, just use BTRFS_SUPER_FLAG_ERROR to make it > simple. > - add MS_RDONLY check at start of a transaction instead of commit transaction. > --- > fs/btrfs/ctree.h | 19 ++++++++++ > fs/btrfs/disk-io.c | 56 +++++++++++++++++++++++++++++- > fs/btrfs/super.c | 88 ++++++++++++++++++++++++++++++++++++++++++++++++ > fs/btrfs/transaction.c | 3 ++ > 4 files changed, 164 insertions(+), 2 deletions(-) > -- > 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 > -- 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
