[PATCH] xfstests: add 'check -btrfs' support
Currently we can specify the testing filesytems like 'check -xfs', but btrfs is not support in this kind of command option. Add the option 'check -btrfs' support. Signed-off-by: Wang Sheng-Hui shh...@gmail.com --- check |2 ++ 1 file changed, 2 insertions(+) diff --git a/check b/check index ff8fbcf..9c40615 100755 --- a/check +++ b/check @@ -74,6 +74,7 @@ usage() check options -xfstest XFS (default) +-btrfs test Btrfs -udftest UDF -nfstest NFS -l line mode diff @@ -162,6 +163,7 @@ while [ $# -gt 0 ]; do -udf) FSTYP=udf ;; -xfs) FSTYP=xfs ;; -nfs) FSTYP=nfs ;; + -btrfs) FSTYP=btrfs ;; -g) group=$2 ; shift ; group_list=$(get_group_list $group) -- 1.7.10.4 -- 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
[PATCH] Btrfs: cleanup redundant code in btrfs_submit_direct()
Signed-off-by: Miao Xie mi...@cn.fujitsu.com
---
fs/btrfs/inode.c | 10 +-
1 file changed, 1 insertion(+), 9 deletions(-)
diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
index 590c274..65ae1cb 100644
--- a/fs/btrfs/inode.c
+++ b/fs/btrfs/inode.c
@@ -7136,7 +7136,6 @@ static void btrfs_submit_direct(int rw, struct bio
*dio_bio,
{
struct btrfs_root *root = BTRFS_I(inode)-root;
struct btrfs_dio_private *dip;
- struct bio_vec *bvec = dio_bio-bi_io_vec;
struct bio *io_bio;
int skip_sum;
int write = rw REQ_WRITE;
@@ -7158,16 +7157,9 @@ static void btrfs_submit_direct(int rw, struct bio
*dio_bio,
}
dip-private = dio_bio-bi_private;
- io_bio-bi_private = dio_bio-bi_private;
dip-inode = inode;
dip-logical_offset = file_offset;
-
- dip-bytes = 0;
- do {
- dip-bytes += bvec-bv_len;
- bvec++;
- } while (bvec = (dio_bio-bi_io_vec + dio_bio-bi_vcnt - 1));
-
+ dip-bytes = dio_bio-bi_size;
dip-disk_bytenr = (u64)dio_bio-bi_sector 9;
io_bio-bi_private = dip;
dip-errors = 0;
--
1.8.1.4
--
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
Re: [PATCH] Btrfs-progs: do not print uuid 0 when printing root item
do not print uuid 0 when printing root item Actually I think we should print all the UUIDs unconditionally. This is inside the debug-tree utility and a zero uuid is an information that may be useful, even if only as one of the results 'grep uuid'. I don't see much point in hiding information here, it's a few more lines per root. david -- 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
[PATCH] Btrfs: check for actual acls rather than just xattrs when caching no acl
We have an optimization that will go ahead and cache no acls on an inode if
there are no xattrs on the inode. This saves us a lookup later to check the
acls for writes or any other access. The problem is I use selinux so I always
have an xattr on inodes, so make this test a little smarter and check for the
actual acl hash on the key and if it isn't there then we still get to cache no
acl which makes everybody who uses selinux a little happier. Thanks,
Signed-off-by: Josef Bacik jba...@fusionio.com
---
fs/btrfs/inode.c | 18 --
1 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
index ecf8b5b..7b9144c 100644
--- a/fs/btrfs/inode.c
+++ b/fs/btrfs/inode.c
@@ -41,6 +41,7 @@
#include linux/mount.h
#include linux/btrfs.h
#include linux/blkdev.h
+#include linux/posix_acl_xattr.h
#include compat.h
#include ctree.h
#include disk-io.h
@@ -56,6 +57,7 @@
#include free-space-cache.h
#include inode-map.h
#include backref.h
+#include hash.h
struct btrfs_iget_args {
u64 ino;
@@ -3300,8 +3302,17 @@ static noinline int acls_after_inode_item(struct
extent_buffer *leaf,
{
u32 nritems = btrfs_header_nritems(leaf);
struct btrfs_key found_key;
+ static u64 xattr_access = 0;
+ static u64 xattr_default = 0;
int scanned = 0;
+ if (!xattr_access) {
+ xattr_access = btrfs_name_hash(POSIX_ACL_XATTR_ACCESS,
+ strlen(POSIX_ACL_XATTR_ACCESS));
+ xattr_default = btrfs_name_hash(POSIX_ACL_XATTR_DEFAULT,
+ strlen(POSIX_ACL_XATTR_DEFAULT));
+ }
+
slot++;
while (slot nritems) {
btrfs_item_key_to_cpu(leaf, found_key, slot);
@@ -3311,8 +3322,11 @@ static noinline int acls_after_inode_item(struct
extent_buffer *leaf,
return 0;
/* we found an xattr, assume we've got an acl */
- if (found_key.type == BTRFS_XATTR_ITEM_KEY)
- return 1;
+ if (found_key.type == BTRFS_XATTR_ITEM_KEY) {
+ if (found_key.offset == xattr_access ||
+ found_key.offset == xattr_default)
+ return 1;
+ }
/*
* we found a key greater than an xattr key, there can't
--
1.7.7.6
--
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
Re: [3.10-rc6] WARNING: at fs/btrfs/inode.c:7961 btrfs_destroy_inode+0x265/0x2e0 [btrfs]()
Quoting Dave Jones (2013-06-17 14:58:10) On Mon, Jun 17, 2013 at 02:42:27PM -0400, Chris Mason wrote: Quoting Dave Jones (2013-06-17 14:20:06) On Mon, Jun 17, 2013 at 01:39:42PM -0400, Chris Mason wrote: Quoting Dave Jones (2013-06-17 09:49:55) Hit this while running this script in a loop.. https://github.com/kernelslacker/io-tests/blob/master/setup.sh [34385.251507] [ cut here ] [34385.254068] WARNING: at fs/btrfs/inode.c:7961 btrfs_destroy_inode+0x265/0x2e0 [btrfs]() Thanks Dave, how long did you have to run the script to trigger it? -chris Judging by the timestamp, about 9 hours. This is on a 3 disk (sata) (oldish) quad opteron. Might repro faster on a more modern machine. Exactly how did you run it? I want to make sure I'm matching your config. while [ 1 ]; do setup.sh done You'll need to set DISK1 etc variables at the top of the script to point to at least 3 disks for it to scribble over. you'll also need fsx and fsstress in /usr/local/bin. I've tried with and without memory pressure, and let it run for about 30 hours. So far, nothing here. Have you seen this again? -chris -- 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
Re: [3.10-rc6] WARNING: at fs/btrfs/inode.c:7961 btrfs_destroy_inode+0x265/0x2e0 [btrfs]()
On Wed, Jun 19, 2013 at 02:02:33PM -0400, Chris Mason wrote: Quoting Dave Jones (2013-06-17 14:58:10) On Mon, Jun 17, 2013 at 02:42:27PM -0400, Chris Mason wrote: Quoting Dave Jones (2013-06-17 14:20:06) On Mon, Jun 17, 2013 at 01:39:42PM -0400, Chris Mason wrote: Quoting Dave Jones (2013-06-17 09:49:55) Hit this while running this script in a loop.. https://github.com/kernelslacker/io-tests/blob/master/setup.sh [34385.251507] [ cut here ] [34385.254068] WARNING: at fs/btrfs/inode.c:7961 btrfs_destroy_inode+0x265/0x2e0 [btrfs]() Thanks Dave, how long did you have to run the script to trigger it? Judging by the timestamp, about 9 hours. This is on a 3 disk (sata) (oldish) quad opteron. Might repro faster on a more modern machine. Exactly how did you run it? I want to make sure I'm matching your config. while [ 1 ]; do setup.sh done You'll need to set DISK1 etc variables at the top of the script to point to at least 3 disks for it to scribble over. you'll also need fsx and fsstress in /usr/local/bin. I've tried with and without memory pressure, and let it run for about 30 hours. So far, nothing here. Have you seen this again? yeah, one time I hit it within 30 minutes. Dave -- 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
Re: [3.10-rc6] WARNING: at fs/btrfs/inode.c:7961 btrfs_destroy_inode+0x265/0x2e0 [btrfs]()
Quoting Dave Jones (2013-06-19 14:34:50) On Wed, Jun 19, 2013 at 02:02:33PM -0400, Chris Mason wrote: Quoting Dave Jones (2013-06-17 14:58:10) On Mon, Jun 17, 2013 at 02:42:27PM -0400, Chris Mason wrote: Quoting Dave Jones (2013-06-17 14:20:06) On Mon, Jun 17, 2013 at 01:39:42PM -0400, Chris Mason wrote: Quoting Dave Jones (2013-06-17 09:49:55) Hit this while running this script in a loop.. https://github.com/kernelslacker/io-tests/blob/master/setup.sh [34385.251507] [ cut here ] [34385.254068] WARNING: at fs/btrfs/inode.c:7961 btrfs_destroy_inode+0x265/0x2e0 [btrfs]() Thanks Dave, how long did you have to run the script to trigger it? Judging by the timestamp, about 9 hours. This is on a 3 disk (sata) (oldish) quad opteron. Might repro faster on a more modern machine. Exactly how did you run it? I want to make sure I'm matching your config. while [ 1 ]; do setup.sh done You'll need to set DISK1 etc variables at the top of the script to point to at least 3 disks for it to scribble over. you'll also need fsx and fsstress in /usr/local/bin. I've tried with and without memory pressure, and let it run for about 30 hours. So far, nothing here. Have you seen this again? yeah, one time I hit it within 30 minutes. Ok, I'll try bumping the thread count on both fsstress and fsx -chris -- 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
[trivial PATCH] treewide: Add __GFP_NOWARN to k.alloc calls with v.alloc fallbacks
Don't emit OOM warnings when k.alloc calls fail when
there there is a v.alloc immediately afterwards.
Converted a kmalloc/vmalloc with memset to kzalloc/vzalloc.
Signed-off-by: Joe Perches j...@perches.com
---
drivers/block/drbd/drbd_bitmap.c | 2 +-
drivers/infiniband/hw/ehca/ipz_pt_fn.c | 3 ++-
drivers/net/ethernet/chelsio/cxgb3/cxgb3_offload.c | 2 +-
drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c| 2 +-
drivers/scsi/cxgbi/libcxgbi.h | 8
fs/btrfs/send.c| 2 +-
fs/ext4/super.c| 4 ++--
fs/gfs2/dir.c | 2 +-
net/sched/sch_choke.c | 3 ++-
9 files changed, 15 insertions(+), 13 deletions(-)
diff --git a/drivers/block/drbd/drbd_bitmap.c b/drivers/block/drbd/drbd_bitmap.c
index 64fbb83..b12c11e 100644
--- a/drivers/block/drbd/drbd_bitmap.c
+++ b/drivers/block/drbd/drbd_bitmap.c
@@ -393,7 +393,7 @@ static struct page **bm_realloc_pages(struct drbd_bitmap
*b, unsigned long want)
* we must not block on IO to ourselves.
* Context is receiver thread or dmsetup. */
bytes = sizeof(struct page *)*want;
- new_pages = kzalloc(bytes, GFP_NOIO);
+ new_pages = kzalloc(bytes, GFP_NOIO | __GFP_NOWARN);
if (!new_pages) {
new_pages = __vmalloc(bytes,
GFP_NOIO | __GFP_HIGHMEM | __GFP_ZERO,
diff --git a/drivers/infiniband/hw/ehca/ipz_pt_fn.c
b/drivers/infiniband/hw/ehca/ipz_pt_fn.c
index 62c71fa..8d59451 100644
--- a/drivers/infiniband/hw/ehca/ipz_pt_fn.c
+++ b/drivers/infiniband/hw/ehca/ipz_pt_fn.c
@@ -222,7 +222,8 @@ int ipz_queue_ctor(struct ehca_pd *pd, struct ipz_queue
*queue,
queue-small_page = NULL;
/* allocate queue page pointers */
- queue-queue_pages = kzalloc(nr_of_pages * sizeof(void *), GFP_KERNEL);
+ queue-queue_pages = kzalloc(nr_of_pages * sizeof(void *),
+GFP_KERNEL | __GFP_NOWARN);
if (!queue-queue_pages) {
queue-queue_pages = vzalloc(nr_of_pages * sizeof(void *));
if (!queue-queue_pages) {
diff --git a/drivers/net/ethernet/chelsio/cxgb3/cxgb3_offload.c
b/drivers/net/ethernet/chelsio/cxgb3/cxgb3_offload.c
index 4058b85..76ae0999 100644
--- a/drivers/net/ethernet/chelsio/cxgb3/cxgb3_offload.c
+++ b/drivers/net/ethernet/chelsio/cxgb3/cxgb3_offload.c
@@ -1157,7 +1157,7 @@ static void cxgb_redirect(struct dst_entry *old, struct
dst_entry *new,
*/
void *cxgb_alloc_mem(unsigned long size)
{
- void *p = kzalloc(size, GFP_KERNEL);
+ void *p = kzalloc(size, GFP_KERNEL | __GFP_NOWARN);
if (!p)
p = vzalloc(size);
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
index 5a3256b..5d5f268 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
@@ -1133,7 +1133,7 @@ out: release_firmware(fw);
*/
void *t4_alloc_mem(size_t size)
{
- void *p = kzalloc(size, GFP_KERNEL);
+ void *p = kzalloc(size, GFP_KERNEL | __GFP_NOWARN);
if (!p)
p = vzalloc(size);
diff --git a/drivers/scsi/cxgbi/libcxgbi.h b/drivers/scsi/cxgbi/libcxgbi.h
index 80fa99b..8135f04 100644
--- a/drivers/scsi/cxgbi/libcxgbi.h
+++ b/drivers/scsi/cxgbi/libcxgbi.h
@@ -658,11 +658,11 @@ static inline u32 cxgbi_tag_nonrsvd_bits(struct
cxgbi_tag_format *tformat,
static inline void *cxgbi_alloc_big_mem(unsigned int size,
gfp_t gfp)
{
- void *p = kmalloc(size, gfp);
+ void *p = kzalloc(size, gfp | __GFP_NOWARN);
+
if (!p)
- p = vmalloc(size);
- if (p)
- memset(p, 0, size);
+ p = vzalloc(size);
+
return p;
}
diff --git a/fs/btrfs/send.c b/fs/btrfs/send.c
index ff40f1c..f7499ed 100644
--- a/fs/btrfs/send.c
+++ b/fs/btrfs/send.c
@@ -219,7 +219,7 @@ static int fs_path_ensure_buf(struct fs_path *p, int len)
len = PAGE_ALIGN(len);
if (p-buf == p-inline_buf) {
- tmp_buf = kmalloc(len, GFP_NOFS);
+ tmp_buf = kmalloc(len, GFP_NOFS | __GFP_NOWARN);
if (!tmp_buf) {
tmp_buf = vmalloc(len);
if (!tmp_buf)
diff --git a/fs/ext4/super.c b/fs/ext4/super.c
index 85b3dd6..0f94f55 100644
--- a/fs/ext4/super.c
+++ b/fs/ext4/super.c
@@ -162,7 +162,7 @@ void *ext4_kvmalloc(size_t size, gfp_t flags)
{
void *ret;
- ret = kmalloc(size, flags);
+ ret = kmalloc(size, flags | __GFP_NOWARN);
if (!ret)
ret = __vmalloc(size, flags, PAGE_KERNEL);
return ret;
@@ -172,7 +172,7 @@ void *ext4_kvzalloc(size_t size, gfp_t flags)
{
void *ret;
- ret = kzalloc(size, flags);
+ ret = kzalloc(size,
[PATCH] Btrfs: use a percpu to keep track of possibly pinned bytes
There are all of these checks in the ENOSPC code to see if committing the
transaction would free up enough space to make the allocation. This is because
early on we just committed the transaction and hoped and prayed, which resulted
in cases where it took _forever_ to get an ENOSPC when we really were out of
space. So we check space_info-bytes_pinned, except this isn't completely true
because it doesn't account for space we may free but are stuck in delayed refs.
So tests like xfstests 226 would fail because we wouldn't commit the transaction
to free up the data space. So instead add a percpu counter that will be a
little fuzzier, it will add bytes as soon as we try to free up the space, and
remove any space it doesn't actually free up when we get around to doing the
actual free. We then 0 out this counter every transaction period so we have a
better idea of how much space we will actually free up by committing this
transaction. With this patch we now pass xfstests 226. Thanks,
Signed-off-by: Josef Bacik jba...@fusionio.com
---
fs/btrfs/ctree.h | 12 ++
fs/btrfs/extent-tree.c | 58 +++
2 files changed, 65 insertions(+), 5 deletions(-)
diff --git a/fs/btrfs/ctree.h b/fs/btrfs/ctree.h
index 76e4983..b528a55 100644
--- a/fs/btrfs/ctree.h
+++ b/fs/btrfs/ctree.h
@@ -1102,6 +1102,18 @@ struct btrfs_space_info {
account */
/*
+* bytes_pinned is kept in line with what is actually pinned, as in
+* we've called update_block_group and dropped the bytes_used counter
+* and increased the bytes_pinned counter. However this means that
+* bytes_pinned does not reflect the bytes that will be pinned once the
+* delayed refs are flushed, so this counter is inc'ed everytime we call
+* btrfs_free_extent so it is a realtime count of what will be freed
+* once the transaction is committed. It will be zero'ed everytime the
+* transaction commits.
+*/
+ struct percpu_counter total_bytes_pinned;
+
+ /*
* we bump reservation progress every time we decrement
* bytes_reserved. This way people waiting for reservations
* know something good has happened and they can check
diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
index 6d5c5f7..806801a 100644
--- a/fs/btrfs/extent-tree.c
+++ b/fs/btrfs/extent-tree.c
@@ -24,6 +24,7 @@
#include linux/kthread.h
#include linux/slab.h
#include linux/ratelimit.h
+#include linux/percpu_counter.h
#include compat.h
#include hash.h
#include ctree.h
@@ -3357,6 +3358,7 @@ static int update_space_info(struct btrfs_fs_info *info,
u64 flags,
struct btrfs_space_info *found;
int i;
int factor;
+ int ret;
if (flags (BTRFS_BLOCK_GROUP_DUP | BTRFS_BLOCK_GROUP_RAID1 |
BTRFS_BLOCK_GROUP_RAID10))
@@ -3380,6 +3382,10 @@ static int update_space_info(struct btrfs_fs_info *info,
u64 flags,
if (!found)
return -ENOMEM;
+ ret = percpu_counter_init(found-total_bytes_pinned, 0);
+ if (ret)
+ return ret;
+
for (i = 0; i BTRFS_NR_RAID_TYPES; i++)
INIT_LIST_HEAD(found-block_groups[i]);
init_rwsem(found-groups_sem);
@@ -3612,10 +3618,11 @@ alloc:
}
/*
-* If we have less pinned bytes than we want to allocate then
-* don't bother committing the transaction, it won't help us.
+* If we don't have enough pinned space to deal with this
+* allocation don't bother committing the transaction.
*/
- if (data_sinfo-bytes_pinned bytes)
+ if (percpu_counter_compare(data_sinfo-total_bytes_pinned,
+ bytes) 0)
committed = 1;
spin_unlock(data_sinfo-lock);
@@ -3624,6 +3631,7 @@ commit_trans:
if (!committed
!atomic_read(root-fs_info-open_ioctl_trans)) {
committed = 1;
+
trans = btrfs_join_transaction(root);
if (IS_ERR(trans))
return PTR_ERR(trans);
@@ -4034,6 +4042,7 @@ static int may_commit_transaction(struct btrfs_root *root,
{
struct btrfs_block_rsv *delayed_rsv = root-fs_info-delayed_block_rsv;
struct btrfs_trans_handle *trans;
+ u64 bytes_pinned;
trans = (struct btrfs_trans_handle *)current-journal_info;
if (trans)
@@ -4044,7 +4053,8 @@ static int may_commit_transaction(struct btrfs_root *root,
/* See if there is enough pinned space to make this reservation */
spin_lock(space_info-lock);
- if (space_info-bytes_pinned = bytes) {
+ if (percpu_counter_compare(space_info-total_bytes_pinned,
+
Re: BUG at fs/btrfs/print-tree when trying to mount after a crash
Hi, here's an update on my situation. On Tue, 2013-06-18 at 14:11 +0200, Michael Zugelder wrote: Anyway, I tried using btrfsck from Josef Bacik's tree (commit f392a28d, git://github.com/josefbacik/btrfs-progs.git) and it doesn't crash. Output is this: Checking filesystem on /dev/mapper/cryptbtrfs UUID: b3a88070-748c-4f19-9c7c-c78e8232797c checking extents corrupt extent record: key 19642421248 168 45056 corrupt extent record: key 19642904576 168 40960 corrupt extent record: key 19643248640 168 49152 corrupt extent record: key 19644252160 168 49152 corrupt extent record: key 19644645376 168 40960 corrupt extent record: key 19645878272 168 4096 corrupt extent record: key 19646754816 168 524288 ref mismatch on [19642265600 53248] extent item 18177, found 1 Backref 19642265600 root 259 owner 1647675 offset 1572864 num_refs 0 not found in extent tree Incorrect local backref count on 19642265600 root 259 owner 1647675 offset 1572864 found 1 wanted 0 back 0x95f91a0 Incorrect local backref count on 19642265600 root 295 owner 1647618 offset 1573046 found 0 wanted 162 back 0x4efb2b0 Backref disk bytenr does not match extent record, bytenr=19642265600, ref bytenr=82290641 backpointer mismatch on [19642265600 53248] Backref 19642318848 root 259 owner 1647675 offset 1703936 num_refs 0 not found in extent tree Incorrect local backref count on 19642318848 root 259 owner 1647675 offset 1703936 found 1 wanted 0 back 0x95f92c0 Incorrect local backref count on 19642318848 root 259 owner 1647675 offset 148434071453696 found 0 wanted 1 back 0x4efb310 Backref disk bytenr does not match extent record, bytenr=19642318848, ref bytenr=1 backpointer mismatch on [19642318848 49152] [ ... ] Errors found in extent allocation tree checking free space cache checking fs roots root 1597 inode 553154 errors 0 unresolved ref dir 473796 index 153 namelen 17 name browser_tests.log filetype 1 error 4 unresolved ref dir 473796 index 17179869337 namelen 17 name brwser_te6ts.log filetype 0 error 3 found 62413098968 bytes used err is 1 total csum bytes: 71717016 total tree bytes: 2047426560 total fs tree bytes: 1812643840 total extent tree bytes: 129286144 btree space waste bytes: 427714485 file data blocks allocated: 186676146176 referenced 125879046144 Btrfs v0.20-rc1 I recently discovered that the git btrfsck has a --repair option. It seems like it was able to fix most of the errors. Here's what I did to get rid of the rest (output from btrfsck): unresolved ref dir 473796 index 153 namelen 17 name browser_tests.log filetype 1 error 4 unresolved ref dir 473796 index 17179869337 namelen 17 name brwser_te6ts.log filetype 0 error 3 Could not delete the file after mounting, so I just deleted the entire subvolume and it is gone now. root 260 inode 12345 errors 42 Used find -num 12345 to see which files referenced it. Since it was just a sqlite journal file, I deleted it. But it was also referenced by the snapshots of the last 24 hours, so I just deleted them, too. cache and super generation don't match, space cache will be invalidated Mounted a few times with -o clear_cache, nospace_cache and then space_cache. Dmesg shows btrfs: disk space caching is enabled and no errors, so I hope it works again. Never noticed any long mount/unmount times or heavy cpu/disk activity, though. Then I ran btrfs scrub over it, which found 0 errors, but there were still some corruption issues from the btrfsck repair. I used rpm -Va and reinstalled a few packages whose files were missing and added myself to the relevant groups again. The system seems to work fine now, but I'll probably keep some easier restorable backups from now on. If you want any details to be able to fix some of the BUGs, assertion errors and/or crashes I encountered, I'm glad to help, still have the original corrupted image. Michael -- 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
Re: csum failed during rebalance
On Jun 19, 2013, at 5:55 PM, John Haller john.h.hal...@gmail.com wrote: It appears that devid 1 was never balanced. Note that the drive numbers are different because I still have the backup device connected which had the originals of corrupted files. The filesystem started with devid 1, was filled to the above capacity, and the other drives were added later, so it didn't start as a RAID 0 system. Did you balance with -dconvert raid0 when you added the additional drives? Chris Murphy -- 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
Re: hang on 3.9, 3.10-rc5
Hi Chris,
On Tue, 18 Jun 2013, Chris Mason wrote:
[...]
Very long way of saying I think we're one release_path short. Sage, I
haven't tested this at all yet, I was hoping to trigger it first.
diff --git a/fs/btrfs/tree-log.c b/fs/btrfs/tree-log.c
index c276ac9..c1954b3 100644
--- a/fs/btrfs/tree-log.c
+++ b/fs/btrfs/tree-log.c
@@ -3730,6 +3730,7 @@ next_slot:
log_extents:
if (fast_search) {
btrfs_release_path(dst_path);
+ btrfs_release_path(path);
ret = btrfs_log_changed_extents(trans, root, inode, dst_path);
if (ret) {
err = ret;
This seems to be doing the trick. I'll keep testing overnight, but so far
so good!
Thanks-
sage
--
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
