2010/11/25, Miao Xie <mi...@cn.fujitsu.com>:
> 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.
Yes, I agree.
>
> 1. For those errors which can be handled well by callers, we just return
> their
> error number to callers.
It's a good idea.
>
> 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.
>
> ---
> fs/btrfs/ctree.h | 21 ++++++++++
> fs/btrfs/disk-io.c | 23 +++++++++++
> fs/btrfs/super.c | 100
> ++++++++++++++++++++++++++++++++++++++++++++++-
> fs/btrfs/transaction.c | 7 +++
> 4 files changed, 148 insertions(+), 3 deletions(-)
>
> --
> 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
