2011-07-06 09:11:11 +0100, Stephane Chazelas:
[...]
extent_map delayed_node btrfs_inode_cache btrfs_free_space_cache
(in bytes)
[...]
01:00 267192640 668595744 23216460003418048
01:10 267192640 668595744 23216460003418048
01:20 267192640 668595744 23216460003418048
Stephane Chazelas wrote:
2011-07-06 09:11:11 +0100, Stephane Chazelas:
[...]
extent_map delayed_node btrfs_inode_cache btrfs_free_space_cache
(in bytes)
[...]
01:00 267192640 668595744 23216460003418048
01:10 267192640 668595744 23216460003418048
01:20 267192640 668595744
2011-07-07 16:20:20 +0800, Li Zefan:
[...]
btrfs_inode_cache is a slab cache for in memory inodes, which is of
struct btrfs_inode.
[...]
Thanks Li.
If that's a cache, the system should be able to reuse the space
there when it's low on memory, wouldn't it? What would be the
conditions where
Hi all, just apologize for my English.
In a nice, warm evening, turn off the electricity, and my router with
btrfs on root, broke ..
I removed the image of a partition (10G), I will now rearrange the
system is probably on ext4 ..
Start the discussion -
The return value check of btrfs_alloc_path() in several places is
changed from BUG_ON() to error return.
Signed-off-by: Tsutomu Itoh t-i...@jp.fujitsu.com
---
fs/btrfs/extent-tree.c |3 ++-
fs/btrfs/extent_io.c |9 ++---
fs/btrfs/inode.c | 15 +++
Josef,
Well that's a neat trick, do you have a way to undo that action too?
Seems a rescan doesn't make it show back up.
hope the following helps..
-
# fdisk -l /dev/sdg | egrep Disk /
Disk /dev/sdg: 4294 MB, 4294967296 bytes
# x=`ls -l /sys/class/block/sdg | cut -d / -f12
Currently, extent_read_full_page always assumes we are trying to read mirror
0, which generally is the best we can do. To add flexibility, pass it as a
parameter. This will be needed by scrub fixup code.
Signed-off-by: Jan Schmidt list.bt...@jan-o-sch.net
---
fs/btrfs/disk-io.c |2 +-
the rest of the code uses int mirror_num, and so should scrub
Signed-off-by: Jan Schmidt list.bt...@jan-o-sch.net
---
fs/btrfs/scrub.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/fs/btrfs/scrub.c b/fs/btrfs/scrub.c
index 15fed35..12c08c0 100644
---
these ioctls make use of the new functions initially added for scrub. they
return all inodes belonging to a logical address (BTRFS_IOC_LOGICAL_INO) and
all paths belonging to an inode (BTRFS_IOC_INO_PATHS).
Signed-off-by: Jan Schmidt list.bt...@jan-o-sch.net
---
fs/btrfs/ioctl.c | 134
These helper functions iterate back references and call a function for each
backref. There is also a function to resolve an inode to a path in the
file system.
Signed-off-by: Jan Schmidt list.bt...@jan-o-sch.net
---
fs/btrfs/Makefile |3 +-
fs/btrfs/backref.c | 748
This patch set introduces two new features for scrub. They share the backref
iteration code which is the reason they made it into the same patch set.
The first feature adds printk statements in case scrub finds an error which list
all affected files. You will need patch 1, 2 and 3 for that.
The
The kernel patch series just sent (Subject: Btrfs: scrub: print path to
corrupted files and trigger nodatasum fixup) introduces two new ioctls to
do in-kernel filesystem path construction. This series provides the
corresponding userspace changes, adding two new commands to the btrfs utility:
--
two new commands that make use of the new path resolving functions
implemented for scrub, doing the resolving in-kernel. the result for both
commands is a list of files belonging to that inode / logical address.
Signed-off-by: Jan Schmidt list.bt...@jan-o-sch.net
---
btrfs-list.c | 35
Signed-off-by: Jan Schmidt list.bt...@jan-o-sch.net
---
scrub.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/scrub.c b/scrub.c
index 22052ed..8270431 100644
--- a/scrub.c
+++ b/scrub.c
@@ -942,6 +942,8 @@ static int scrub_fs_info(int fd, char *path,
Excerpts from Tsutomu Itoh's message of 2011-07-01 04:11:28 -0400:
Hi, Miao,
(2011/06/30 15:32), Miao Xie wrote:
Hi, Itoh-san
Could you test the following patch to check whether it can fix the bug or
not?
I have tested it on my x86_64 machine by your test script for two days, it
Hi, Jan,
On Thu, Jul 07, 2011 at 05:48:33PM +0200, Jan Schmidt wrote:
these ioctls make use of the new functions initially added for scrub. they
return all inodes belonging to a logical address (BTRFS_IOC_LOGICAL_INO) and
all paths belonging to an inode (BTRFS_IOC_INO_PATHS).
I've not
Hi,
On 07/08/2011 12:29 AM, Hugo Mills wrote:
Hi, Jan,
On Thu, Jul 07, 2011 at 05:48:33PM +0200, Jan Schmidt wrote:
these ioctls make use of the new functions initially added for scrub. they
return all inodes belonging to a logical address (BTRFS_IOC_LOGICAL_INO) and
all paths belonging
Hi, Chris,
(2011/07/08 5:26), Chris Mason wrote:
Excerpts from Tsutomu Itoh's message of 2011-07-01 04:11:28 -0400:
Hi, Miao,
(2011/06/30 15:32), Miao Xie wrote:
Hi, Itoh-san
Could you test the following patch to check whether it can fix the bug or
not?
I have tested it on my x86_64
Excerpts from Tsutomu Itoh's message of 2011-07-07 19:51:09 -0400:
Hi, Chris,
(2011/07/08 5:26), Chris Mason wrote:
Excerpts from Tsutomu Itoh's message of 2011-07-01 04:11:28 -0400:
Hi, Miao,
(2011/06/30 15:32), Miao Xie wrote:
Hi, Itoh-san
Could you test the following patch to
Hi, Chris,
(2011/07/08 5:26), Chris Mason wrote:
Excerpts from Tsutomu Itoh's message of 2011-07-01 04:11:28 -0400:
Hi, Miao,
(2011/06/30 15:32), Miao Xie wrote:
Hi, Itoh-san
Could you test the following patch to check whether it can fix the bug or
not?
I have tested it on my x86_64
20 matches
Mail list logo
