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
This patch provide a new error handle interface for those errors that handled
by current BUG_ONs.
In order to protect btrfs from panic, when it comes to those BUG_ON errors,
the interface forces btrfs readonly and saves the FS state to disk. And the
filesystem can be umounted, although mabye
When the filesystem is readonly, avoid transaction stuff by checking MS_RDONLY
at start transaction time.
Signed-off-by: Liu Bo liubo2...@cn.fujitsu.com
---
fs/btrfs/transaction.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/fs/btrfs/transaction.c
Add filesystem state and a flags to tell if the filesystem is
valid or insane now.
Signed-off-by: Liu Bo liubo2...@cn.fujitsu.com
---
fs/btrfs/ctree.h | 11 +++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/fs/btrfs/ctree.h b/fs/btrfs/ctree.h
index 8db9234..92b5ca2
Since there is a filesystem state, we should deal with it carefully at mount,
umount and remount.
- At mount, the FS state should be checked if there is error on these FS.
If it does have, btrfsck is recommended.
- At umount, the FS state should be saved into disk for consistency.
v2-v3:
do
btrfs may do log replay even as mounted readonly, since we have added
readonly check at start transaction time, in order to keep the original
attribute, it needs to set and to restore readonly flags around log
replay.
However, we do not permit log replay when btrfs is insane, and log replay
can
On Mon, Nov 29, 2010 at 11:42 AM, C Anthony Risinger anth...@extof.me wrote:
On Sun, Nov 28, 2010 at 4:07 AM, C Anthony Risinger anth...@extof.me wrote:
On Nov 27, 2010, at 10:22 PM, Calvin Walton calvin.wal...@gmail.com
wrote:
On Sat, 2010-11-27 at 21:19 -0600, C Anthony Risinger wrote:
eg.
2010/12/2 David Pottage da...@electric-spoon.com:
Therefore I think it is a bad idea if potentially different files on btrfs
can have the same inode number. It will break all sorts of tools.
Instead of maintaining a big complicated reference count of used inode
numbers, could btrfs use bit
On Thu, Dec 02, 2010 at 11:25:01PM -0500, Chris Ball wrote:
Hi Josef,
1) Scrap the 256 inode number thing. Instead we'll just put a
flag in the inode to say Hey, I'm a subvolume and then we can
do all of the appropriate magic that way. This unfortunately
will be an
Currently if the space cache inode generation number doesn't match the
generation number in the space cache header we will just fail to load the space
cache, but we won't mark the space cache as an error, so we'll keep getting that
error each time somebody tries to cache that block group until we
On Wed, Dec 01, 2010 at 09:21:36AM -0500, Josef Bacik wrote:
Hello,
Various people have complained about how BTRFS deals with subvolumes recently,
specifically the fact that they all have the same inode number, and there's no
discrete seperation from one subvolume to another. Christoph
On Fri, Dec 03, 2010 at 04:45:27PM -0500, Josef Bacik wrote:
So now that I've actually looked at everything, it looks like the semantics
are
all right for subvolumes
1) readdir - we return the root id in d_ino, which is unique across the fs
Though Michael Vrable pointed out an apparent
On Fri, Dec 03, 2010 at 04:45:27PM -0500, Josef Bacik wrote:
On Wed, Dec 01, 2010 at 09:21:36AM -0500, Josef Bacik wrote:
Hello,
Various people have complained about how BTRFS deals with subvolumes
recently,
specifically the fact that they all have the same inode number, and there's
Excerpts from Dave Chinner's message of 2010-12-03 17:27:56 -0500:
On Fri, Dec 03, 2010 at 04:45:27PM -0500, Josef Bacik wrote:
On Wed, Dec 01, 2010 at 09:21:36AM -0500, Josef Bacik wrote:
Hello,
Various people have complained about how BTRFS deals with subvolumes
recently,
On Fri, Dec 03, 2010 at 05:29:24PM -0500, Chris Mason wrote:
Excerpts from Dave Chinner's message of 2010-12-03 17:27:56 -0500:
On Fri, Dec 03, 2010 at 04:45:27PM -0500, Josef Bacik wrote:
On Wed, Dec 01, 2010 at 09:21:36AM -0500, Josef Bacik wrote:
Hello,
Various people have
On 2010-12-03, at 15:45, J. Bruce Fields wrote:
We're using statfs64.fs_fsid for this; I believe that's both stable
across reboots and distinguishes between subvolumes, so that's OK.
(That said, since fs_fsid doesn't work for other filesystems, we depend
on an explicit check for a filesystem
16 matches
Mail list logo
