Having parent transid verify failed
Hello, I have a 5.5TB Btrfs filesystem on top of a md-raid 5 device. Now if i run some file operations like find, i get these messages. kernel is 2.6.38.5-1 on arch linux May 5 14:15:12 mail kernel: [13559.089713] parent transid verify failed on 3062073683968 wanted 5181 found 5188 May 5 14:15:12 mail kernel: [13559.089834] parent transid verify failed on 3062073683968 wanted 5181 found 5188 May 5 14:15:14 mail kernel: [13560.752074] btrfs-transacti D 88007211ac78 0 5339 2 0x May 5 14:15:14 mail kernel: [13560.752078] 880023167d30 0046 8800 8800195b6000 May 5 14:15:14 mail kernel: [13560.752082] 880023167c10 02c8f27b4000 880023167fd8 88007211a9a0 May 5 14:15:14 mail kernel: [13560.752085] 880023167fd8 880023167fd8 88007211ac80 880023167fd8 May 5 14:15:14 mail kernel: [13560.752087] Call Trace: May 5 14:15:14 mail kernel: [13560.752101] [a0850d02] ? run_clustered_refs+0x132/0x830 [btrfs] May 5 14:15:14 mail kernel: [13560.752105] [813aff3d] schedule_timeout+0x2fd/0x380 May 5 14:15:14 mail kernel: [13560.752108] [813b0cf9] ? mutex_unlock+0x9/0x10 May 5 14:15:14 mail kernel: [13560.752115] [a087e9f4] ? btrfs_run_ordered_operations+0x1f4/0x210 [btrfs] May 5 14:15:14 mail kernel: [13560.752122] [a0860fa3] btrfs_commit_transaction+0x263/0x750 [btrfs] May 5 14:15:14 mail kernel: [13560.752126] [81079ff0] ? autoremove_wake_function+0x0/0x40 May 5 14:15:14 mail kernel: [13560.752131] [a085a9bd] transaction_kthread+0x26d/0x290 [btrfs] May 5 14:15:14 mail kernel: [13560.752137] [a085a750] ? transaction_kthread+0x0/0x290 [btrfs] May 5 14:15:14 mail kernel: [13560.752139] [81079717] kthread+0x87/0x90 May 5 14:15:14 mail kernel: [13560.752142] [8100bc24] kernel_thread_helper+0x4/0x10 May 5 14:15:14 mail kernel: [13560.752145] [81079690] ? kthread+0x0/0x90 May 5 14:15:14 mail kernel: [13560.752147] [8100bc20] ? kernel_thread_helper+0x0/0x10 May 5 14:15:17 mail kernel: [13564.092081] verify_parent_transid: 40736 callbacks suppressed May 5 14:15:17 mail kernel: [13564.092084] parent transid verify failed on 3062073683968 wanted 5181 found 5188 --snip-- May 5 14:17:13 mail kernel: [13679.169772] parent transid verify failed on 3062073683968 wanted 5181 found 5188 --snip-- May 5 14:17:14 mail kernel: [13680.751996] btrfs-transacti D 88007211ac78 0 5339 2 0x May 5 14:17:14 mail kernel: [13680.752000] 880023167d30 0046 8800 8800195b6000 May 5 14:17:14 mail kernel: [13680.752004] 880023167c10 02c8f27b4000 880023167fd8 88007211a9a0 May 5 14:17:14 mail kernel: [13680.752006] 880023167fd8 880023167fd8 88007211ac80 880023167fd8 May 5 14:17:14 mail kernel: [13680.752009] Call Trace: May 5 14:17:14 mail kernel: [13680.752024] [a0850d02] ? run_clustered_refs+0x132/0x830 [btrfs] May 5 14:17:14 mail kernel: [13680.752030] [813aff3d] schedule_timeout+0x2fd/0x380 May 5 14:17:14 mail kernel: [13680.752032] [813b0cf9] ? mutex_unlock+0x9/0x10 May 5 14:17:14 mail kernel: [13680.752040] [a087e9f4] ? btrfs_run_ordered_operations+0x1f4/0x210 [btrfs] May 5 14:17:14 mail kernel: [13680.752046] [a0860fa3] btrfs_commit_transaction+0x263/0x750 [btrfs] May 5 14:17:14 mail kernel: [13680.752051] [81079ff0] ? autoremove_wake_function+0x0/0x40 May 5 14:17:14 mail kernel: [13680.752057] [a085a9bd] transaction_kthread+0x26d/0x290 [btrfs] May 5 14:17:14 mail kernel: [13680.752062] [a085a750] ? transaction_kthread+0x0/0x290 [btrfs] May 5 14:17:14 mail kernel: [13680.752065] [81079717] kthread+0x87/0x90 May 5 14:17:14 mail kernel: [13680.752068] [8100bc24] kernel_thread_helper+0x4/0x10 May 5 14:17:14 mail kernel: [13680.752070] [81079690] ? kthread+0x0/0x90 May 5 14:17:14 mail kernel: [13680.752072] [8100bc20] ? kernel_thread_helper+0x0/0x10 May 5 14:17:14 mail kernel: [13680.752079] dd D 8800714c4838 0 5792 5740 0x0004 May 5 14:17:14 mail kernel: [13680.752082] 88006a205b38 0082 88006a205af8 0246 May 5 14:17:14 mail kernel: [13680.752085] ea00017f57e8 88006a205fd8 88006a205fd8 8800714c4560 May 5 14:17:14 mail kernel: [13680.752088] 88006a205fd8 88006a205fd8 8800714c4840 88006a205fd8 May 5 14:17:14 mail kernel: [13680.752090] Call Trace: May 5 14:17:14 mail kernel: [13680.752095] [810ff145] ? zone_statistics+0x75/0x90 May 5 14:17:14 mail kernel: [13680.752098] [810ea8b7] ? get_page_from_freelist+0x3c7/0x820 May 5 14:17:14 mail kernel: [13680.752101] [810e3588] ? find_get_page+0x68/0xb0 May 5 14:17:14 mail kernel: [13680.752108] [a08603f9]
Re: Having parent transid verify failed
Excerpts from Konstantinos Skarlatos's message of 2011-05-05 07:19:52 -0400: Hello, I have a 5.5TB Btrfs filesystem on top of a md-raid 5 device. Now if i run some file operations like find, i get these messages. kernel is 2.6.38.5-1 on arch linux Are all of the messages for this one block? parent transid verify failed on 3062073683968 wanted 5181 found 5188 -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: Having parent transid verify failed
On 5/5/2011 2:42 μμ, Chris Mason wrote: Excerpts from Konstantinos Skarlatos's message of 2011-05-05 07:19:52 -0400: Hello, I have a 5.5TB Btrfs filesystem on top of a md-raid 5 device. Now if i run some file operations like find, i get these messages. kernel is 2.6.38.5-1 on arch linux Are all of the messages for this one block? parent transid verify failed on 3062073683968 wanted 5181 found 5188 yes, only this block -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
[PATCH 0/3] Cleanups II, unused code removal
Hi, another round of cleanups, removing unused code. No functional chanes. The diffstat is quite big, please have a look if you feel that some code is unused by accident. thanks, david David Sterba (3): btrfs: remove unused function prototypes btrfs: remove all unused functions btrfs: remove old unused commented out code fs/btrfs/ctree.h| 90 --- fs/btrfs/delayed-ref.c | 114 --- fs/btrfs/delayed-ref.h |6 - fs/btrfs/disk-io.c | 56 -- fs/btrfs/disk-io.h | 18 - fs/btrfs/extent-tree.c | 1661 +-- fs/btrfs/extent_io.c| 227 -- fs/btrfs/extent_io.h| 30 - fs/btrfs/free-space-cache.c | 15 - fs/btrfs/free-space-cache.h |1 - fs/btrfs/inode.c| 224 -- fs/btrfs/locking.c | 25 - fs/btrfs/locking.h |2 - fs/btrfs/ref-cache.c| 164 - fs/btrfs/ref-cache.h| 24 - fs/btrfs/relocation.c |2 +- fs/btrfs/root-tree.c| 47 -- fs/btrfs/sysfs.c| 65 -- fs/btrfs/transaction.c | 134 fs/btrfs/transaction.h |3 - fs/btrfs/tree-log.h |1 - fs/btrfs/volumes.c | 19 - fs/btrfs/volumes.h |5 - 23 files changed, 2 insertions(+), 2931 deletions(-) -- 1.7.5.1.169.g505a1 -- 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 2/3] btrfs: remove all unused functions
Remove static and global declarations and/or definitions. Reduces size
of btrfs.ko by ~3.4kB.
textdata bss dec hex filename
4020817464 200 409745 64091 btrfs.ko.base
3986207144 200 405964 631cc btrfs.ko.remove-all
Signed-off-by: David Sterba dste...@suse.cz
---
fs/btrfs/ctree.h| 78 ---
fs/btrfs/delayed-ref.c | 38 ---
fs/btrfs/delayed-ref.h |1 -
fs/btrfs/disk-io.c | 27 -
fs/btrfs/disk-io.h |7 --
fs/btrfs/extent_io.c| 227 ---
fs/btrfs/extent_io.h| 21
fs/btrfs/free-space-cache.c | 15 ---
fs/btrfs/free-space-cache.h |1 -
fs/btrfs/inode.c| 52 --
fs/btrfs/locking.c | 25 -
fs/btrfs/locking.h |2 -
fs/btrfs/ref-cache.c| 164 ---
fs/btrfs/ref-cache.h| 24 -
fs/btrfs/relocation.c |2 +-
fs/btrfs/root-tree.c| 47 -
fs/btrfs/sysfs.c| 65
fs/btrfs/volumes.c | 19
fs/btrfs/volumes.h |3 -
19 files changed, 1 insertions(+), 817 deletions(-)
diff --git a/fs/btrfs/ctree.h b/fs/btrfs/ctree.h
index b66216e..e37d441 100644
--- a/fs/btrfs/ctree.h
+++ b/fs/btrfs/ctree.h
@@ -1440,26 +1440,12 @@ static inline u64 btrfs_stripe_offset_nr(struct
extent_buffer *eb,
return btrfs_stripe_offset(eb, btrfs_stripe_nr(c, nr));
}
-static inline void btrfs_set_stripe_offset_nr(struct extent_buffer *eb,
-struct btrfs_chunk *c, int nr,
-u64 val)
-{
- btrfs_set_stripe_offset(eb, btrfs_stripe_nr(c, nr), val);
-}
-
static inline u64 btrfs_stripe_devid_nr(struct extent_buffer *eb,
struct btrfs_chunk *c, int nr)
{
return btrfs_stripe_devid(eb, btrfs_stripe_nr(c, nr));
}
-static inline void btrfs_set_stripe_devid_nr(struct extent_buffer *eb,
-struct btrfs_chunk *c, int nr,
-u64 val)
-{
- btrfs_set_stripe_devid(eb, btrfs_stripe_nr(c, nr), val);
-}
-
/* struct btrfs_block_group_item */
BTRFS_SETGET_STACK_FUNCS(block_group_used, struct btrfs_block_group_item,
used, 64);
@@ -1517,14 +1503,6 @@ btrfs_inode_ctime(struct btrfs_inode_item *inode_item)
return (struct btrfs_timespec *)ptr;
}
-static inline struct btrfs_timespec *
-btrfs_inode_otime(struct btrfs_inode_item *inode_item)
-{
- unsigned long ptr = (unsigned long)inode_item;
- ptr += offsetof(struct btrfs_inode_item, otime);
- return (struct btrfs_timespec *)ptr;
-}
-
BTRFS_SETGET_FUNCS(timespec_sec, struct btrfs_timespec, sec, 64);
BTRFS_SETGET_FUNCS(timespec_nsec, struct btrfs_timespec, nsec, 32);
@@ -1875,33 +1853,6 @@ static inline u8 *btrfs_header_chunk_tree_uuid(struct
extent_buffer *eb)
return (u8 *)ptr;
}
-static inline u8 *btrfs_super_fsid(struct extent_buffer *eb)
-{
- unsigned long ptr = offsetof(struct btrfs_super_block, fsid);
- return (u8 *)ptr;
-}
-
-static inline u8 *btrfs_header_csum(struct extent_buffer *eb)
-{
- unsigned long ptr = offsetof(struct btrfs_header, csum);
- return (u8 *)ptr;
-}
-
-static inline struct btrfs_node *btrfs_buffer_node(struct extent_buffer *eb)
-{
- return NULL;
-}
-
-static inline struct btrfs_leaf *btrfs_buffer_leaf(struct extent_buffer *eb)
-{
- return NULL;
-}
-
-static inline struct btrfs_header *btrfs_buffer_header(struct extent_buffer
*eb)
-{
- return NULL;
-}
-
static inline int btrfs_is_leaf(struct extent_buffer *eb)
{
return btrfs_header_level(eb) == 0;
@@ -2055,22 +2006,6 @@ static inline struct btrfs_root *btrfs_sb(struct
super_block *sb)
return sb-s_fs_info;
}
-static inline int btrfs_set_root_name(struct btrfs_root *root,
- const char *name, int len)
-{
- /* if we already have a name just free it */
- kfree(root-name);
-
- root-name = kmalloc(len+1, GFP_KERNEL);
- if (!root-name)
- return -ENOMEM;
-
- memcpy(root-name, name, len);
- root-name[len] = '\0';
-
- return 0;
-}
-
static inline u32 btrfs_level_size(struct btrfs_root *root, int level)
{
if (level == 0)
@@ -2304,11 +2239,6 @@ static inline int btrfs_del_item(struct
btrfs_trans_handle *trans,
int btrfs_insert_item(struct btrfs_trans_handle *trans, struct btrfs_root
*root, struct btrfs_key *key, void *data, u32 data_size);
-int btrfs_insert_some_items(struct btrfs_trans_handle *trans,
- struct btrfs_root *root,
- struct btrfs_path *path,
- struct btrfs_key *cpu_key, u32 *data_size,
- int nr);
int
[PATCH 1/3] btrfs: remove unused function prototypes
function prototypes without a body Signed-off-by: David Sterba dste...@suse.cz --- fs/btrfs/ctree.h | 12 fs/btrfs/delayed-ref.h |5 - fs/btrfs/disk-io.h | 11 --- fs/btrfs/extent_io.h |9 - fs/btrfs/transaction.h |3 --- fs/btrfs/tree-log.h|1 - fs/btrfs/volumes.h |2 -- 7 files changed, 0 insertions(+), 43 deletions(-) diff --git a/fs/btrfs/ctree.h b/fs/btrfs/ctree.h index 3f301f0..b66216e 100644 --- a/fs/btrfs/ctree.h +++ b/fs/btrfs/ctree.h @@ -2108,12 +2108,9 @@ int btrfs_lookup_extent_info(struct btrfs_trans_handle *trans, u64 num_bytes, u64 *refs, u64 *flags); int btrfs_pin_extent(struct btrfs_root *root, u64 bytenr, u64 num, int reserved); -int btrfs_drop_leaf_ref(struct btrfs_trans_handle *trans, - struct btrfs_root *root, struct extent_buffer *leaf); int btrfs_cross_ref_exist(struct btrfs_trans_handle *trans, struct btrfs_root *root, u64 objectid, u64 offset, u64 bytenr); -int btrfs_copy_pinned(struct btrfs_root *root, struct extent_io_tree *copy); struct btrfs_block_group_cache *btrfs_lookup_block_group( struct btrfs_fs_info *info, u64 bytenr); @@ -2463,15 +2460,10 @@ int btrfs_csum_file_blocks(struct btrfs_trans_handle *trans, struct btrfs_ordered_sum *sums); int btrfs_csum_one_bio(struct btrfs_root *root, struct inode *inode, struct bio *bio, u64 file_start, int contig); -int btrfs_csum_file_bytes(struct btrfs_root *root, struct inode *inode, - u64 start, unsigned long len); struct btrfs_csum_item *btrfs_lookup_csum(struct btrfs_trans_handle *trans, struct btrfs_root *root, struct btrfs_path *path, u64 bytenr, int cow); -int btrfs_csum_truncate(struct btrfs_trans_handle *trans, - struct btrfs_root *root, struct btrfs_path *path, - u64 isize); int btrfs_lookup_csums_range(struct btrfs_root *root, u64 start, u64 end, struct list_head *list); /* inode.c */ @@ -2520,7 +2512,6 @@ unsigned long btrfs_force_ra(struct address_space *mapping, int btrfs_page_mkwrite(struct vm_area_struct *vma, struct vm_fault *vmf); int btrfs_readpage(struct file *file, struct page *page); void btrfs_evict_inode(struct inode *inode); -void btrfs_put_inode(struct inode *inode); int btrfs_write_inode(struct inode *inode, struct writeback_control *wbc); void btrfs_dirty_inode(struct inode *inode); struct inode *btrfs_alloc_inode(struct super_block *sb); @@ -2531,8 +2522,6 @@ void btrfs_destroy_cachep(void); long btrfs_ioctl_trans_end(struct file *file); struct inode *btrfs_iget(struct super_block *s, struct btrfs_key *location, struct btrfs_root *root, int *was_new); -int btrfs_commit_write(struct file *file, struct page *page, - unsigned from, unsigned to); struct extent_map *btrfs_get_extent(struct inode *inode, struct page *page, size_t pg_offset, u64 start, u64 end, int create); @@ -2571,7 +2560,6 @@ void btrfs_inherit_iflags(struct inode *inode, struct inode *dir); int btrfs_sync_file(struct file *file, int datasync); int btrfs_drop_extent_cache(struct inode *inode, u64 start, u64 end, int skip_pinned); -int btrfs_check_file(struct btrfs_root *root, struct inode *inode); extern const struct file_operations btrfs_file_operations; int btrfs_drop_extents(struct btrfs_trans_handle *trans, struct inode *inode, u64 start, u64 end, u64 *hint_byte, int drop_cache); diff --git a/fs/btrfs/delayed-ref.h b/fs/btrfs/delayed-ref.h index 50e3cf9..946ed71 100644 --- a/fs/btrfs/delayed-ref.h +++ b/fs/btrfs/delayed-ref.h @@ -167,11 +167,6 @@ int btrfs_add_delayed_extent_op(struct btrfs_trans_handle *trans, struct btrfs_delayed_ref_head * btrfs_find_delayed_ref_head(struct btrfs_trans_handle *trans, u64 bytenr); int btrfs_delayed_ref_pending(struct btrfs_trans_handle *trans, u64 bytenr); -int btrfs_update_delayed_ref(struct btrfs_trans_handle *trans, - u64 bytenr, u64 num_bytes, u64 orig_parent, - u64 parent, u64 orig_ref_root, u64 ref_root, - u64 orig_ref_generation, u64 ref_generation, - u64 owner_objectid, int pin); int btrfs_delayed_ref_lock(struct btrfs_trans_handle *trans, struct btrfs_delayed_ref_head *head); int btrfs_find_ref_cluster(struct btrfs_trans_handle *trans, diff --git a/fs/btrfs/disk-io.h b/fs/btrfs/disk-io.h index 07b20dc..758f3ca 100644
[PATCH] btrfs progs: fix extra metadata chunk allocation in --mixed case
When creating a mixed fs with mkfs, an extra metadata chunk got allocated.
This is because btrfs_reserve_extent calls do_chunk_alloc for METADATA,
which in turn wasn't able to find the proper space_info, as __find_space_info
did a hard compare of the flags. It is now sufficient for the space_info to
include the proper flag. This reflects the change done to the kernel code
to support mixed chunks.
Also for a subsequent chunk allocation (which should not be hit in the mkfs
case), the chunk is now created with the flags from the space_info instead
of the requested flags. A better solution would be to pull the full changeset
for the mixed case from the kernel into the user mode (or, even better, share
the code)
The additional chunk probably confused block_rsv calculation, which in turn
led to severeal ENOSPC Oopses.
Signed-off-by: Arne Jansen sensi...@gmx.net
---
extent-tree.c |7 ---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/extent-tree.c b/extent-tree.c
index b2f9bb2..c6c77c6 100644
--- a/extent-tree.c
+++ b/extent-tree.c
@@ -1735,7 +1735,7 @@ static struct btrfs_space_info *__find_space_info(struct
btrfs_fs_info *info,
struct btrfs_space_info *found;
list_for_each(cur, head) {
found = list_entry(cur, struct btrfs_space_info, list);
- if (found-flags == flags)
+ if (found-flags flags)
return found;
}
return NULL;
@@ -1812,7 +1812,8 @@ static int do_chunk_alloc(struct btrfs_trans_handle
*trans,
thresh)
return 0;
- ret = btrfs_alloc_chunk(trans, extent_root, start, num_bytes, flags);
+ ret = btrfs_alloc_chunk(trans, extent_root, start, num_bytes,
+ space_info-flags);
if (ret == -ENOSPC) {
space_info-full = 1;
return 0;
@@ -1820,7 +1821,7 @@ static int do_chunk_alloc(struct btrfs_trans_handle
*trans,
BUG_ON(ret);
- ret = btrfs_make_block_group(trans, extent_root, 0, flags,
+ ret = btrfs_make_block_group(trans, extent_root, 0, space_info-flags,
BTRFS_FIRST_CHUNK_TREE_OBJECTID, start, num_bytes);
BUG_ON(ret);
return 0;
--
1.7.3.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: Having parent transid verify failed
Excerpts from Konstantinos Skarlatos's message of 2011-05-05 07:45:08 -0400: On 5/5/2011 2:42 μμ, Chris Mason wrote: Excerpts from Konstantinos Skarlatos's message of 2011-05-05 07:19:52 -0400: Hello, I have a 5.5TB Btrfs filesystem on top of a md-raid 5 device. Now if i run some file operations like find, i get these messages. kernel is 2.6.38.5-1 on arch linux Are all of the messages for this one block? parent transid verify failed on 3062073683968 wanted 5181 found 5188 yes, only this block Ok, what were the call traces in there? Was there an oops or a hung task? It looks like part of the messages are missing. -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: [PATCH] Btrfs: fix easily get into ENOSPC in mixed case
On Fri, 08 Apr 2011 16:44:37 +0800
liubo liubo2...@cn.fujitsu.com wrote:
When a btrfs disk is created by mixed data metadata option, it will have no
pure data or pure metadata space info.
In btrfs's for-linus branch, commit 78b1ea13838039cd88afdd62519b40b344d6c920
(Btrfs: fix OOPS of empty filesystem after balance) initializes space infos at
the very beginning. The problem is this initialization does not take the
mixed
case into account, which will cause btrfs will easily get into ENOSPC in mixed
case.
Signed-off-by: Liu Bo liubo2...@cn.fujitsu.com
Hi Chris!
I confirm it fixes OOpses for me.
Some clarification of what happened down the thread with me in order to convince
this patch actually makes things better.
1. The initial OOps reported by me was a result of using bad mkfs (not
interesting,
but generated a lot of noise here)
2. Then I've patched mkfs properly (used tmp branch), reformatted my partitions
and
caught -ENOSPC on 'rm -rf /var/tmp/' (vanilla kernel), added debugging info
and have come to the
conclusion: this patch helps in this situation, as free space was
completely miscomputed
(it's a regression since 2.6.38). I've applied it and things _mostly_ (see
3.) solved (--mixed
~4G lzo filesystem) for me
3. Then I've caught more -ENOSPC oopses, which occured to be a bug in mkfs for
which Arne posted
a fix today, see his email:
[PATCH] btrfs progs: fix extra metadata chunk allocation in --mixed case
Arne's mkfs patch (or btrfs fi balance workaround) fixed rest of OOpses for
me.
So, my thoughts:
- this patch is quite critical for --mixed filesystems
- it (or it's equivalent) should be considered for pulling-in to .39 kernel
(ideally), as it's a regression since 2.6.38
Thanks!
---
fs/btrfs/extent-tree.c | 37 ++---
1 files changed, 26 insertions(+), 11 deletions(-)
diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
index f619c3c..1b47ae4 100644
--- a/fs/btrfs/extent-tree.c
+++ b/fs/btrfs/extent-tree.c
@@ -8781,23 +8781,38 @@ out:
int btrfs_init_space_info(struct btrfs_fs_info *fs_info)
{
struct btrfs_space_info *space_info;
+ struct btrfs_super_block *disk_super;
+ u64 features;
+ u64 flags;
+ int mixed = 0;
int ret;
- ret = update_space_info(fs_info, BTRFS_BLOCK_GROUP_SYSTEM, 0, 0,
- space_info);
- if (ret)
- return ret;
+ disk_super = fs_info-super_copy;
+ if (!btrfs_super_root(disk_super))
+ return 1;
- ret = update_space_info(fs_info, BTRFS_BLOCK_GROUP_METADATA, 0, 0,
- space_info);
- if (ret)
- return ret;
+ features = btrfs_super_incompat_flags(disk_super);
+ if (features BTRFS_FEATURE_INCOMPAT_MIXED_GROUPS)
+ mixed = 1;
- ret = update_space_info(fs_info, BTRFS_BLOCK_GROUP_DATA, 0, 0,
- space_info);
+ flags = BTRFS_BLOCK_GROUP_SYSTEM;
+ ret = update_space_info(fs_info, flags, 0, 0, space_info);
if (ret)
- return ret;
+ goto out;
+ if (mixed) {
+ flags = BTRFS_BLOCK_GROUP_METADATA | BTRFS_BLOCK_GROUP_DATA;
+ ret = update_space_info(fs_info, flags, 0, 0, space_info);
+ } else {
+ flags = BTRFS_BLOCK_GROUP_METADATA;
+ ret = update_space_info(fs_info, flags, 0, 0, space_info);
+ if (ret)
+ goto out;
+
+ flags = BTRFS_BLOCK_GROUP_DATA;
+ ret = update_space_info(fs_info, flags, 0, 0, space_info);
+ }
+out:
return ret;
}
--
1.6.5.2
--
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
--
Sergei
signature.asc
Description: PGP signature
Re: Cannot Deinstall a Debian Package
On Wednesday 4 May, 2011 02:51:54 Sander wrote: Put an exit on top of /etc/kernel/postrm.d/zz-update-grub and try again. Install grub-pc 1.99~rc1-13 from Sid. First I put an exit right after #! /bin/sh and it failed. Then I moved /etc/kernel/postrm.d/zz-update-grub to / and it still failed. Grub is not running as a daemon, so I shouldn't have to reboot for the new version to take effect. And frankly at the moment I'm afraid to reboot, with only grub-common installed. # dpkg -i /var/cache/apt/archives/grub-common_1.99~rc1-13_amd64.deb (Reading database ... 136689 files and directories currently installed.) Preparing to replace grub-common 1.98+20100804-14 (using .../grub-common_1.99~rc1-13_amd64.deb) ... Unpacking replacement grub-common ... Setting up grub-common (1.99~rc1-13) ... Installing new version of config file /etc/grub.d/10_linux ... Installing new version of config file /etc/grub.d/30_os-prober ... Installing new version of config file /etc/grub.d/00_header ... Installing new version of config file /etc/grub.d/20_linux_xen ... Processing triggers for install-info ... Processing triggers for man-db ... # dpkg -i /var/cache/apt/archives/grub-pc_1.99~rc1-13_amd64.deb (Reading database ... 136703 files and directories currently installed.) Preparing to replace grub-pc 1.99~rc1-13 (using .../grub-pc_1.99~rc1-13_amd64.deb) ... Unpacking replacement grub-pc ... Setting up grub-pc (1.99~rc1-13) ... grub-probe: error: cannot stat `/dev/root'. Installation finished. No error reported. /usr/sbin/grub-probe: error: cannot stat `/dev/root'. dpkg: error processing grub-pc (--install): subprocess installed post-installation script returned error exit status 1 Processing triggers for man-db ... Errors were encountered while processing: grub-pc -- 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: Having parent transid verify failed
Excerpts from Konstantinos Skarlatos's message of 2011-05-05 10:27:30 -0400: attached you can find the whole dmesg log. I can trigger the error again if more logs are needed Yes, I'll send you a patch to get rid of the printk for the transid failed message. That way we can get a clean view of the other errors. Will you be able to compile/test it? -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: Having parent transid verify failed
On 5/5/2011 6:06 μμ, Chris Mason wrote: Excerpts from Konstantinos Skarlatos's message of 2011-05-05 10:27:30 -0400: attached you can find the whole dmesg log. I can trigger the error again if more logs are needed Yes, I'll send you a patch to get rid of the printk for the transid failed message. That way we can get a clean view of the other errors. Will you be able to compile/test it? Yes, i think i will be able to make it, but because i have only done this once and in a quite hackish way, i may need some help in order to do it right. -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: kernel BUG at fs/btrfs/inode.c:149!
On Thu, May 05, 2011 at 02:12:03PM +0200, wh...@gmx.com wrote: Seems like the mail didn't get trough, trying again with the logfile compressed. Thanks, On Wednesday 04 May 2011 20:21:54 you wrote: [...] Argh sorry I was looking at the wrong part of that warning. Can you run with this debug patch and send me the log? Thanks, Josef I hope that's enough, the log buffer was too small to keep the whole thing. Hmm I didn't see what I needed, can you do it again and try to get kernel messages to go to /var/log/messages so you don't have to worry about the log buffer? The other option is to setup netconsole which would grab everything. Thanks, Josef -- 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: Cannot Deinstall a Debian Package
Anyone have a suggestion? Also on another machine set up similarly, I now cannot mkdir. It says 'no space left on device'. df says: # df /dev/sdb Filesystem 1K-blocks Used Available Use% Mounted on /dev/sdb 3907029168 2658010524 1246486516 69% /home sdb and sdc are one btrfs 'raid' volume. What could be wrong? On Thursday 5 May, 2011 07:49:09 cac...@quantum-sci.com wrote: On Wednesday 4 May, 2011 02:51:54 Sander wrote: Put an exit on top of /etc/kernel/postrm.d/zz-update-grub and try again. Install grub-pc 1.99~rc1-13 from Sid. First I put an exit right after #! /bin/sh and it failed. Then I moved /etc/kernel/postrm.d/zz-update-grub to / and it still failed. Grub is not running as a daemon, so I shouldn't have to reboot for the new version to take effect. And frankly at the moment I'm afraid to reboot, with only grub-common installed. # dpkg -i /var/cache/apt/archives/grub-common_1.99~rc1-13_amd64.deb (Reading database ... 136689 files and directories currently installed.) Preparing to replace grub-common 1.98+20100804-14 (using .../grub-common_1.99~rc1-13_amd64.deb) ... Unpacking replacement grub-common ... Setting up grub-common (1.99~rc1-13) ... Installing new version of config file /etc/grub.d/10_linux ... Installing new version of config file /etc/grub.d/30_os-prober ... Installing new version of config file /etc/grub.d/00_header ... Installing new version of config file /etc/grub.d/20_linux_xen ... Processing triggers for install-info ... Processing triggers for man-db ... # dpkg -i /var/cache/apt/archives/grub-pc_1.99~rc1-13_amd64.deb (Reading database ... 136703 files and directories currently installed.) Preparing to replace grub-pc 1.99~rc1-13 (using .../grub-pc_1.99~rc1-13_amd64.deb) ... Unpacking replacement grub-pc ... Setting up grub-pc (1.99~rc1-13) ... grub-probe: error: cannot stat `/dev/root'. Installation finished. No error reported. /usr/sbin/grub-probe: error: cannot stat `/dev/root'. dpkg: error processing grub-pc (--install): subprocess installed post-installation script returned error exit status 1 Processing triggers for man-db ... Errors were encountered while processing: grub-pc -- 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
Re: Is it possible for the ext4/btrfs file system to pass some context related info to low level block driver?
On Wed, May 04, 2011 at 08:51:39AM -0600, Andreas Dilger wrote: I was aware of REQ_META, but I didn't know there was any benefit to using it. I think it would be easy to set REQ_META on all ext4 metadata if there was a reason to do so. The CFQ ioscheduler pays attention to it (prioritising metadata accesses over data accesses), and blocktrace will print an 'M' for metadata requests if it's set, so I think that's two excellent reasons to set REQ_META today. However, ext3, ext4, and XFS already use it: fs/ext3/inode.c:1105: ll_rw_block(READ_META, 1, bh); fs/ext3/inode.c:2754: submit_bh(READ_META, bh); fs/ext3/namei.c:924:ll_rw_block(READ_META, 1, bh); fs/ext4/inode.c:1500: ll_rw_block(READ_META, 1, bh); fs/ext4/inode.c:4775: submit_bh(READ_META, bh); fs/ext4/namei.c:924:ll_rw_block(READ_META, 1, bh); fs/gfs2/log.c:597: submit_bh(WRITE_SYNC | REQ_META, bh); fs/gfs2/log.c:599: submit_bh(WRITE_FLUSH_FUA | REQ_META, bh); fs/gfs2/meta_io.c:39: int write_op = REQ_META | fs/gfs2/meta_io.c:228: submit_bh(READ_SYNC | REQ_META, bh); fs/gfs2/meta_io.c:435: ll_rw_block(READ_SYNC | REQ_META, 1, first_bh); fs/gfs2/ops_fstype.c:221: submit_bio(READ_SYNC | REQ_META, bio); fs/gfs2/quota.c:710:ll_rw_block(READ_META, 1, bh); fs/xfs/linux-2.6/xfs_buf.c:1321:rw = (bp-b_flags XBF_WRITE) ? WRITE_META : READ_META; include/linux/fs.h:164:#define READ_META(READ | REQ_META) include/linux/fs.h:168:#define WRITE_META (WRITE | REQ_META) btrfs seems to not use REQ_META yet. *poke* *poke* :-) -- Matthew Wilcox Intel Open Source Technology Centre Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step. -- 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: kernel BUG at fs/btrfs/inode.c:149!
On 05/05/2011 01:54 PM, wh...@gmx.com wrote: On Thursday 05 May 2011 19:53:52 Josef Bacik wrote: [...] Hmm I didn't see what I needed, can you do it again and try to get kernel messages to go to /var/log/messages so you don't have to worry about the log buffer? The other option is to setup netconsole which would grab everything. Thanks, Ok, this is all of it. It doesn't look like that bit had my debugging output. Thanks, Josef -- 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 1/2 v2] fs: add SEEK_HOLE and SEEK_DATA flags
Il 05/05/2011 21:01, Josef Bacik ha scritto:
On 05/05/2011 02:54 PM, Marco Stornelli wrote:
Il 04/05/2011 19:58, Josef Bacik ha scritto:
+ if (offset= i_size_read(inode)) {
+ mutex_unlock(inode-i_mutex);
+ return -ENXIO;
+ }
+ offset = i_size_read(inode);
+ break;
Here maybe it's possible to use offset bigger than i_size, because
i_size_read is atomic but something can happen between two calls,
isn't it?
We're holding the i_mutex so we are safe, i_size_read is used just for
consistency sake. Thanks,
Josef
Oh, I'm sorry, I misread the patch, ok. Maybe we can use i_size at this
point without i_size_read.
Marco
--
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: Cannot Deinstall a Debian Package
On Thu, May 5, 2011 at 12:09 PM, cac...@quantum-sci.com wrote: Anyone have a suggestion? Also on another machine set up similarly, I now cannot mkdir. It says 'no space left on device'. df says: # df /dev/sdb Filesystem 1K-blocks Used Available Use% Mounted on /dev/sdb 3907029168 2658010524 1246486516 69% /home sdb and sdc are one btrfs 'raid' volume. What could be wrong? Which kernel version (uname -a), and what's the output of btrfs fi df /home and sudo btrfs fi show /dev/sdb? -- 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 1/2 v2] fs: add SEEK_HOLE and SEEK_DATA flags
Il 04/05/2011 19:58, Josef Bacik ha scritto:
+ if (offset= i_size_read(inode)) {
+ mutex_unlock(inode-i_mutex);
+ return -ENXIO;
+ }
+ offset = i_size_read(inode);
+ break;
I can add that generic_file_llseek_unlocked means *unlocked* so you
shouldn't unlock any mutex but only return a value. The current version,
in case of SEEK_END uses directly i_size indeed, so maybe I'm missing
something.
Marco
--
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: Cannot Deinstall a Debian Package
On Thu, May 5, 2011 at 8:49 AM, cac...@quantum-sci.com wrote: On Wednesday 4 May, 2011 02:51:54 Sander wrote: Put an exit on top of /etc/kernel/postrm.d/zz-update-grub and try again. Install grub-pc 1.99~rc1-13 from Sid. First I put an exit right after #! /bin/sh and it failed. Then I moved /etc/kernel/postrm.d/zz-update-grub to / and it still failed. Grub is not running as a daemon, so I shouldn't have to reboot for the new version to take effect. And frankly at the moment I'm afraid to reboot, with only grub-common installed. # dpkg -i /var/cache/apt/archives/grub-common_1.99~rc1-13_amd64.deb (Reading database ... 136689 files and directories currently installed.) Preparing to replace grub-common 1.98+20100804-14 (using .../grub-common_1.99~rc1-13_amd64.deb) ... Unpacking replacement grub-common ... Setting up grub-common (1.99~rc1-13) ... Installing new version of config file /etc/grub.d/10_linux ... Installing new version of config file /etc/grub.d/30_os-prober ... Installing new version of config file /etc/grub.d/00_header ... Installing new version of config file /etc/grub.d/20_linux_xen ... Processing triggers for install-info ... Processing triggers for man-db ... # dpkg -i /var/cache/apt/archives/grub-pc_1.99~rc1-13_amd64.deb (Reading database ... 136703 files and directories currently installed.) Preparing to replace grub-pc 1.99~rc1-13 (using .../grub-pc_1.99~rc1-13_amd64.deb) ... Unpacking replacement grub-pc ... Setting up grub-pc (1.99~rc1-13) ... grub-probe: error: cannot stat `/dev/root'. Installation finished. No error reported. /usr/sbin/grub-probe: error: cannot stat `/dev/root'. dpkg: error processing grub-pc (--install): subprocess installed post-installation script returned error exit status 1 Processing triggers for man-db ... Errors were encountered while processing: grub-pc -- 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 You'll need to contact somebody more familiar with debian, as this isn't really a btrfs issue. Yes, btrfs is the obvious cause, but it's grub's handling of it that is the problem, and dpkg's handling of grub's failure that is really blocking you. This is what it meant by does debian support btrfs?. It's not a question of whether btrfs is in debian's kernel, but whether all the pieces of debian which are directly or indirectly affected by btrfs are known to work right, and whether they're currently willing to spend effort on these issues. If they're not currently providing that level of support, then it's completely up to you to have a good understanding of how the rest of debian is put together so that you yourself can make things works. As was mentioned previously, there is an updated grub package, so your main objective is to find out from debian how to disable or override the failing package long enough to install the replacement. -- 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 1/2 v2] fs: add SEEK_HOLE and SEEK_DATA flags
On 05/05/2011 03:19 PM, Marco Stornelli wrote:
Il 04/05/2011 19:58, Josef Bacik ha scritto:
+ if (offset= i_size_read(inode)) {
+ mutex_unlock(inode-i_mutex);
+ return -ENXIO;
+ }
+ offset = i_size_read(inode);
+ break;
I can add that generic_file_llseek_unlocked means *unlocked* so you
shouldn't unlock any mutex but only return a value. The current version,
in case of SEEK_END uses directly i_size indeed, so maybe I'm missing
something.
Yeah this was a copy+paste mistake, ext4 has it's own llseek that I
modified to run my tests against and then I just copied and pasted it
over to the generic things. I've fixed this earlier, I'll be sending a
refreshed set out soon. Thanks,
Josef
--
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: Cannot Deinstall a Debian Package
I was afraid of this finger-pointing. Of course no one at Debian is going to know how to fix BTRFS jamming the package management system. That's ridiculous. It's starting to look like BTRFS is just busted in Debian, and I'll have to reinstall everything over a different filesystem. I hate to give up btrfs raid and snapshotting, but these failures are just unlivable. Is Oracle aware of this? I'll have to warn others in the various forums that BTRFS breaks Debian, because no one warned me. This is unlivable, not to mention unbelievable. On Thursday 5 May, 2011 12:28:19 cwillu wrote: You'll need to contact somebody more familiar with debian, as this isn't really a btrfs issue. Yes, btrfs is the obvious cause, but it's grub's handling of it that is the problem, and dpkg's handling of grub's failure that is really blocking you. This is what it meant by does debian support btrfs?. It's not a question of whether btrfs is in debian's kernel, but whether all the pieces of debian which are directly or indirectly affected by btrfs are known to work right, and whether they're currently willing to spend effort on these issues. If they're not currently providing that level of support, then it's completely up to you to have a good understanding of how the rest of debian is put together so that you yourself can make things works. As was mentioned previously, there is an updated grub package, so your main objective is to find out from debian how to disable or override the failing package long enough to install the replacement. -- 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: Cannot Deinstall a Debian Package
Excerpts from CACook's message of 2011-05-05 15:50:02 -0400: I was afraid of this finger-pointing. We're not finger pointing, but we also don't maintain the script that is failing. I'm happy to patch up bugs in the FS (or point you to newer kernels that have them fixed) but at this point we don't have enough info to say if it is an FS problem or a debian package problem. Perhaps if you ran it under strace? Other distros don't have problems with btrfs on /, so somehow this is specific to debian's setup. -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: Is it possible for the ext4/btrfs file system to pass some context related info to low level block driver?
On May 5, 2011, at 12:10, Matthew Wilcox wrote: On Wed, May 04, 2011 at 08:51:39AM -0600, Andreas Dilger wrote: I was aware of REQ_META, but I didn't know there was any benefit to using it. I think it would be easy to set REQ_META on all ext4 metadata if there was a reason to do so. The CFQ ioscheduler pays attention to it (prioritising metadata accesses over data accesses), and blocktrace will print an 'M' for metadata requests if it's set, so I think that's two excellent reasons to set REQ_META today. However, ext3, ext4, and XFS already use it: fs/ext4/inode.c:1500: ll_rw_block(READ_META, 1, bh); - ext4_bread() fs/ext4/inode.c:4775: submit_bh(READ_META, bh); - __ext4_get_inode_loc() fs/ext4/namei.c:924:ll_rw_block(READ_META, 1, bh); - ext4_find_entry() Looking more closely at the code it seems that this is handling only a subset of the code. There are many places in ext4 that are using sb_bread() instead of ext4_bread(), in particular in the extents and migration code that was developed more recently, but also in the xattr code which has been around a long time. Cheers, Andreas -- 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 1/3 v3] fs: add SEEK_HOLE and SEEK_DATA flags
This just gets us ready to support the SEEK_HOLE and SEEK_DATA flags. Turns out
using fiemap in things like cp cause more problems than it solves, so lets try
and give userspace an interface that doesn't suck. So we have
-SEEK_HOLE: move the file position to the start of the next hole greater than or
equal to the start of the suplied offset. This is how solaris defines it, so
thats how it will work for us. The only trick is preallocated space. Some
filesystems will be able to safely differentiate between prealloced space and
soon to be converted prealloced space, so preallocated space could easily be
considered a hole. At the same time some file systems will not be able to make
this differentiation and so for safety will not treat preallocated space as a
hole.
-SEEK_DATA: this is obviously a little more self-explanatory. Again the only
ambiguity comes in with preallocated extents. If you have an fs that can't
reliably tell that the preallocated extent is in the process of turning into a
real extent, it is correct for SEEK_DATA to park you at a preallocated extent.
In the generic case we will just assume the entire file is data and there is a
virtual hole at i_size, so SEEK_DATA will return -ENXIO unless you provide an
offset of 0 and the file size is larger than 0, and SEEK_HOLE will put you at
i_size unless pos is larger or equal to i_size.
Thanks,
Signed-off-by: Josef Bacik jo...@redhat.com
---
v2-v3:
-Fixed i_mutex unlock screw up
-Just use inode-i_size
-Make the comments clear that we mean the next hole
fs/read_write.c| 18 ++
include/linux/fs.h |4 +++-
2 files changed, 21 insertions(+), 1 deletions(-)
diff --git a/fs/read_write.c b/fs/read_write.c
index 5520f8a..af9cc51 100644
--- a/fs/read_write.c
+++ b/fs/read_write.c
@@ -64,6 +64,24 @@ generic_file_llseek_unlocked(struct file *file, loff_t
offset, int origin)
return file-f_pos;
offset += file-f_pos;
break;
+ case SEEK_DATA:
+ /*
+* In the generic case the entire file is data, so data only
+* starts at position 0 provided the file has an i_size,
+* otherwise it's an empty file and will always be ENXIO.
+*/
+ if (offset != 0 || inode-i_size == 0)
+ return -ENXIO;
+ break;
+ case SEEK_HOLE:
+ /*
+* There is a virtual hole at the end of the file, so as long as
+* offset isn't i_size or larger, return i_size.
+*/
+ if (offset = inode-i_size)
+ return -ENXIO;
+ offset = inode-i_size;
+ break;
}
if (offset 0 !unsigned_offsets(file))
diff --git a/include/linux/fs.h b/include/linux/fs.h
index dbd860a..185b278 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -31,7 +31,9 @@
#define SEEK_SET 0 /* seek relative to beginning of file */
#define SEEK_CUR 1 /* seek relative to current file position */
#define SEEK_END 2 /* seek relative to end of file */
-#define SEEK_MAX SEEK_END
+#define SEEK_HOLE 3 /* seek to the next hole */
+#define SEEK_DATA 4 /* seek to the next data */
+#define SEEK_MAX SEEK_DATA
struct fstrim_range {
__u64 start;
--
1.7.2.3
--
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 3/3 v3] Ext4: handle SEEK_HOLE/SEEK_DATA generically
Since Ext4 has its own lseek we need to make sure it handles
SEEK_HOLE/SEEK_DATA. For now just do the same thing that is done in the generic
case, somebody else can come along and make it do fancy things later. Thanks,
Signed-off-by: Josef Bacik jo...@redhat.com
---
v2-v3: Nothing since this is the first time posting this :)
fs/ext4/file.c | 21 +
1 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/fs/ext4/file.c b/fs/ext4/file.c
index 7b80d54..7ec6e2d 100644
--- a/fs/ext4/file.c
+++ b/fs/ext4/file.c
@@ -236,6 +236,27 @@ loff_t ext4_llseek(struct file *file, loff_t offset, int
origin)
}
offset += file-f_pos;
break;
+ case SEEK_DATA:
+ /*
+* For now the entire file is considered data, so the only valid
+* next data section is position 0.
+*/
+ if (offset != 0 || inode-i_size == 0) {
+ mutex_unlock(inode-i_mutex);
+ return -ENXIO;
+ }
+ break;
+ case SEEK_HOLE:
+ /*
+* There is a virtual hole at the end of the file, so as long as
+* offset isn't i_size or larger, return i_size.
+*/
+ if (offset = inode-i_size) {
+ mutex_unlock(inode-i_mutex);
+ return -ENXIO;
+ }
+ offset = inode-i_size;
+ break;
}
if (offset 0 || offset maxbytes) {
--
1.7.2.3
--
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
[TEST] test the seek_hole/seek_data functionality
This is my very rough tester for testing seek_hole/seek_data. Please look over
it and make sure we all agree that the semantics are correct. My btrfs patch
passes with this and ext3 passes as well. I still have to added fallocate() to
it, but for now this seems to cover most of the corner cases. Thanks,
Josef
#include sys/types.h
#include sys/stat.h
#include errno.h
#include fcntl.h
#include stdio.h
#include string.h
#include unistd.h
#define SEEK_HOLE 3
#define SEEK_DATA 4
#define ERROR(str) \
fprintf(stderr, %s: pos=%lu, errno=%d\n, str, pos, errno)
static int reset_file(int fd)
{
int ret;
ret = ftruncate(fd, 0);
if (ret 0) {
fprintf(stderr, Truncate failed: %d\n, errno);
return 1;
}
return 0;
}
int main(int argc, char **argv)
{
char buf[4096 * 4];
ssize_t bytes;
off_t pos;
int prealloc_is_hole = 0;
int whole_file_is_data = 0;
int ret;
int i;
int fd;
fd = open(testfile, O_RDWR|O_CREAT|O_TRUNC, 0644);
if (fd 0) {
fprintf(stderr, Failed to open testfile: %d\n, errno);
return 1;
}
/* Empty file */
printf(Testing an empty file\n);
pos = lseek(fd, 0, SEEK_DATA);
if (pos != -1) {
if (errno == EINVAL) {
fprintf(stderr, Kernel does not support seek
hole/data\n);
close(fd);
return 1;
}
if (errno != ENXIO)
ERROR(Seek data did not return a proper error);
close(fd);
return 1;
}
pos = lseek(fd, 0, SEEK_HOLE);
if (pos != -1 errno != ENXIO) {
ERROR(Seek hole did not return a proper error);
close(fd);
return 1;
}
memset(buf, 'a', 4096 * 4);
/*
* All data file
*/
printf(Testing a normal data filled file\n);
for (i = 0; i 4; i++) {
bytes = write(fd, buf, 4096);
if (bytes 4096) {
fprintf(stderr, Failed to write to testfile: %d\n,
errno);
close(fd);
return 1;
}
}
pos = lseek(fd, 0, SEEK_HOLE);
if (pos != (4096 * 4) || pos == -1) {
ERROR(Seek hole failed to dump us out at the end of the file);
close(fd);
return 1;
}
pos = lseek(fd, 0, SEEK_DATA);
if (pos != 0) {
ERROR(Seek data failed to dump us out at the beginning of the
file);
close(fd);
return 1;
}
/*
* File with a hole at the front and data at the end
*/
printf(Testing file with hole at the start and data in the rest\n);
if (reset_file(fd)) {
close(fd);
return 1;
}
bytes = pwrite(fd, buf, 4096 * 3, 4096);
if (bytes (4096 * 3)) {
fprintf(stderr, Failed to write to testfile: %d\n);
close(fd);
return 1;
}
pos = lseek(fd, 0, SEEK_HOLE);
if (pos != 0 pos != (4096 * 4)) {
ERROR(Seek hole failed to return 0);
close(fd);
return 1;
} else if (pos == (4096 * 4)) {
whole_file_is_data = 1;
printf(Current file system views treats the entire file as
data\n);
}
pos = lseek(fd, 0, SEEK_DATA);
if (pos != 4096 (pos != 0 whole_file_is_data)) {
if (whole_file_is_data)
ERROR(Seek data failed to return 0);
else
ERROR(Seek data failed to return 4096);
close(fd);
return 1;
}
if (whole_file_is_data) {
pos = lseek(fd, 1, SEEK_DATA);
if (pos != -1 errno != ENXIO) {
ERROR(Seek data failed to retun an error);
close(fd);
return 1;
}
}
/*
* File with a hole at the end and data at the beginning
*/
printf(Testing file with hole at the end and data at the beginning\n);
if (reset_file(fd)) {
close(fd);
return 1;
}
ret = ftruncate(fd, 4096 * 4);
if (ret 0) {
fprintf(stderr, Truncate failed: %d\n, errno);
close(fd);
return 1;
}
pwrite(fd, buf, 4096 * 3, 0);
if (bytes (4096 * 3)) {
fprintf(stderr, Failed to write to testfile: %d\n, errno);
[PATCH 2/3 v3] Btrfs: implement our own -llseek
In order to handle SEEK_HOLE/SEEK_DATA we need to implement our own llseek.
Basically for the normal SEEK_*'s we will just defer to the generic helper, and
for SEEK_HOLE/SEEK_DATA we will use our fiemap helper to figure out the nearest
hole or data. Currently this helper doesn't check for delalloc bytes for
prealloc space, so for now treat prealloc as data until that is fixed. Thanks,
Signed-off-by: Josef Bacik jo...@redhat.com
---
v2-v3: added a cond_resched() to the while loop
fs/btrfs/ctree.h |3 +
fs/btrfs/file.c | 129 +-
2 files changed, 131 insertions(+), 1 deletions(-)
diff --git a/fs/btrfs/ctree.h b/fs/btrfs/ctree.h
index d5f043e..d2991c8 100644
--- a/fs/btrfs/ctree.h
+++ b/fs/btrfs/ctree.h
@@ -2474,6 +2474,9 @@ int btrfs_csum_truncate(struct btrfs_trans_handle *trans,
int btrfs_lookup_csums_range(struct btrfs_root *root, u64 start,
u64 end, struct list_head *list);
/* inode.c */
+struct extent_map *btrfs_get_extent_fiemap(struct inode *inode, struct page
*page,
+ size_t pg_offset, u64 start, u64 len,
+ int create);
/* RHEL and EL kernels have a patch that renames PG_checked to FsMisc */
#if defined(ClearPageFsMisc) !defined(ClearPageChecked)
diff --git a/fs/btrfs/file.c b/fs/btrfs/file.c
index cd5e82e..3a1e401 100644
--- a/fs/btrfs/file.c
+++ b/fs/btrfs/file.c
@@ -1406,8 +1406,135 @@ out:
return ret;
}
+static int find_desired_extent(struct inode *inode, loff_t *offset, int origin)
+{
+ struct btrfs_root *root = BTRFS_I(inode)-root;
+ struct extent_map *em;
+ struct extent_state *cached_state = NULL;
+ u64 lockstart = *offset;
+ u64 lockend = i_size_read(inode);
+ u64 start = *offset;
+ u64 len = i_size_read(inode);
+ u64 last_end = 0;
+ int ret = 0;
+
+ lockend = max_t(u64, BTRFS_I(inode)-root-sectorsize, lockend);
+ len = lockend;
+
+ lock_extent_bits(BTRFS_I(inode)-io_tree, lockstart, lockend, 0,
+cached_state, GFP_NOFS);
+
+ /*
+* Delalloc is such a pain. If we have a hole and we have pending
+* delalloc for a portion of the hole we will get back a hole that
+* exists for the entire range since it hasn't been actually written
+* yet. So to take care of this case we need to look for an extent just
+* before the position we want in case there is outstanding delalloc
+* going on here.
+*/
+ if (origin == SEEK_HOLE start != 0) {
+ if (start root-sectorsize)
+ em = btrfs_get_extent_fiemap(inode, NULL, 0, 0,
+start, 0);
+ else
+ em = btrfs_get_extent_fiemap(inode, NULL, 0,
+start - root-sectorsize,
+root-sectorsize, 0);
+ if (IS_ERR(em)) {
+ ret = -ENXIO;
+ goto out;
+ }
+ last_end = em-start + em-len;
+ free_extent_map(em);
+ }
+
+ while (1) {
+ em = btrfs_get_extent_fiemap(inode, NULL, 0, start, len, 0);
+ if (IS_ERR(em)) {
+ ret = -ENXIO;
+ break;
+ }
+
+ if (em-block_start == EXTENT_MAP_HOLE) {
+ if (origin == SEEK_HOLE) {
+ u64 new_offset = max(em-start, start);
+ /*
+* If we are in the middle of a hole then move
+* to the next one, unless the previous range we
+* found ended here, which means we have a
+* delalloc range that is going to convert part
+* of this hole into data.
+*/
+ if (new_offset == em-start ||
+ (new_offset em-start
+new_offset == last_end)) {
+ *offset = new_offset;
+ free_extent_map(em);
+ break;
+ }
+ }
+ } else {
+ if (origin == SEEK_DATA) {
+ if (em-start == start) {
+ *offset = em-start;
+ free_extent_map(em);
+ break;
+ }
+ }
+ }
+ start = em-start + em-len;
+ last_end = em-start +
Re: Having parent transid verify failed
I think i made some progress. When i tried to remove the directory that i suspect contains the problematic file, i got this on the console rm -rf serverloft/ 2011 May 5 23:32:53 mail [ 200.580195] Oops: [#1] PREEMPT SMP 2011 May 5 23:32:53 mail [ 200.580220] last sysfs file: /sys/module/vt/parameters/default_utf8 2011 May 5 23:32:53 mail [ 200.581145] Stack: 2011 May 5 23:32:53 mail [ 200.581276] Call Trace: 2011 May 5 23:32:53 mail [ 200.581732] Code: cc 00 00 48 8d 91 28 e0 ff ff 48 89 e5 48 81 ec 90 00 00 00 48 89 5d d8 4c 89 65 e0 48 89 f3 4c 89 6d e8 4c 89 75 f0 4c 89 7d f8 48 8b 76 30 83 42 1c 01 48 b8 00 00 00 00 00 16 00 00 48 01 f0 2011 May 5 23:32:53 mail [ 200.583376] CR2: 0030 here is the part of dmesg that does not contain the thousands of parent transid verify failed messages May 5 23:32:51 mail kernel: [ 198.371084] parent transid verify failed on 3062073683968 wanted 5181 found 5188 May 5 23:32:51 mail kernel: [ 198.371204] parent transid verify failed on 3062073683968 wanted 5181 found 5188 May 5 23:32:53 mail kernel: [ 200.572774] Modules linked in: ipv6 btrfs zlib_deflate crc32c libcrc32c ext2 raid456 async_raid6_recov async_pq raid6_pq async_xor xor async_memcpy async_tx md_mod usb_storage uas snd_seq_dummy snd_seq_oss radeon snd_seq_midi_event ttm snd_seq snd_hda_codec_hdmi snd_seq_device drm_kms_helper ohci_hcd snd_hda_intel snd_hda_codec snd_pcm_oss snd_hwdep drm i2c_algo_bit snd_mixer_oss snd_pcm i2c_piix4 snd_timer snd soundcore snd_page_alloc ehci_hcd wmi i2c_core usbcore evdev processor button k10temp serio_raw pcspkr sg r8169 edac_core shpchp pci_hotplug edac_mce_amd mii sp5100_tco ext4 mbcache jbd2 crc16 sd_mod pata_acpi ahci libahci pata_atiixp libata scsi_mod May 5 23:32:53 mail kernel: [ 200.572808] Pid: 1037, comm: btrfs-transacti Not tainted 2.6.38-ARCH #1 May 5 23:32:53 mail kernel: [ 200.572810] Call Trace: May 5 23:32:53 mail kernel: [ 200.572817] [813a932b] ? __schedule_bug+0x59/0x5d May 5 23:32:53 mail kernel: [ 200.572820] [813af827] ? schedule+0x9f7/0xad0 May 5 23:32:53 mail kernel: [ 200.572823] [811e5827] ? generic_unplug_device+0x37/0x40 May 5 23:32:53 mail kernel: [ 200.572827] [a07ac164] ? md_raid5_unplug_device+0x64/0x110 [raid456] May 5 23:32:53 mail kernel: [ 200.572830] [a07ac223] ? raid5_unplug_queue+0x13/0x20 [raid456] May 5 23:32:53 mail kernel: [ 200.572833] [81012d79] ? read_tsc+0x9/0x20 May 5 23:32:53 mail kernel: [ 200.572837] [8108418c] ? ktime_get_ts+0xac/0xe0 May 5 23:32:53 mail kernel: [ 200.572840] [810e36c0] ? sync_page+0x0/0x50 May 5 23:32:53 mail kernel: [ 200.572842] [813af96e] ? io_schedule+0x6e/0xb0 May 5 23:32:53 mail kernel: [ 200.572844] [810e36fb] ? sync_page+0x3b/0x50 May 5 23:32:53 mail kernel: [ 200.572846] [813b0077] ? __wait_on_bit+0x57/0x80 May 5 23:32:53 mail kernel: [ 200.572848] [810e38c0] ? wait_on_page_bit+0x70/0x80 May 5 23:32:53 mail kernel: [ 200.572851] [8107a030] ? wake_bit_function+0x0/0x40 May 5 23:32:53 mail kernel: [ 200.572861] [a08348d2] ? read_extent_buffer_pages+0x412/0x480 [btrfs] May 5 23:32:53 mail kernel: [ 200.572867] [a0809e00] ? btree_get_extent+0x0/0x1b0 [btrfs] May 5 23:32:53 mail kernel: [ 200.572873] [a080ac7e] ? btree_read_extent_buffer_pages.isra.60+0x5e/0xb0 [btrfs] May 5 23:32:53 mail kernel: [ 200.572880] [a080c0bc] ? read_tree_block+0x3c/0x60 [btrfs] May 5 23:32:53 mail kernel: [ 200.572884] [a07f272b] ? read_block_for_search.isra.34+0x1fb/0x410 [btrfs] May 5 23:32:53 mail kernel: [ 200.572890] [a08417d1] ? btrfs_tree_unlock+0x51/0x60 [btrfs] May 5 23:32:53 mail kernel: [ 200.572895] [a07f5ca0] ? btrfs_search_slot+0x430/0xa30 [btrfs] May 5 23:32:53 mail kernel: [ 200.572900] [a07fb3a6] ? lookup_inline_extent_backref+0x96/0x460 [btrfs] May 5 23:32:53 mail kernel: [ 200.572904] [8112b8d3] ? kmem_cache_alloc+0x133/0x150 May 5 23:32:53 mail kernel: [ 200.572908] [a07fd452] ? __btrfs_free_extent+0xc2/0x6d0 [btrfs] May 5 23:32:53 mail kernel: [ 200.572914] [a0800f59] ? run_clustered_refs+0x389/0x830 [btrfs] May 5 23:32:53 mail kernel: [ 200.572920] [a084d900] ? btrfs_find_ref_cluster+0x10/0x190 [btrfs] May 5 23:32:53 mail kernel: [ 200.572925] [a08014c0] ? btrfs_run_delayed_refs+0xc0/0x210 [btrfs] May 5 23:32:53 mail kernel: [ 200.572927] [813b0cf9] ? mutex_unlock+0x9/0x10 May 5 23:32:53 mail kernel: [ 200.572933] [a0810db8] ? btrfs_commit_transaction+0x78/0x750 [btrfs] May 5 23:32:53 mail kernel: [ 200.572936] [81079ff0] ? autoremove_wake_function+0x0/0x40 May 5 23:32:53 mail kernel: [ 200.572941] [a080a9bd] ? transaction_kthread+0x26d/0x290 [btrfs] May 5 23:32:53 mail kernel:
Re: Cannot Deinstall a Debian Package
On Thu, May 5, 2011 at 1:50 PM, cac...@quantum-sci.com wrote: I was afraid of this finger-pointing. Of course no one at Debian is going to know how to fix BTRFS jamming the package management system. That's ridiculous. I took the liberty of asking #debian, and they've requested that you file a bug in their bug tracker. They've also suggested that you might be able to short-circuit the faulty script in their kernel package via an exit 0, or even replace the faulty grub-probe by manually extracting the newer version of the package. -- 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: Cannot Deinstall a Debian Package
Here is the relevant section of strace:
-
chmod(/etc/grub.d/05_debian_theme.dpkg-new, 0755) = 0
unlink(/etc/grub.d/05_debian_theme.dpkg-new) = 0
stat(/etc/localtime, {st_mode=S_IFREG|0644, st_size=2819, ...}) = 0
write(6, 2011-05-05 13:21:57 status unpac..., 56) = 56
write(4, Package: grub-pc\nStatus: install..., 1795) = 1795
ftruncate(4, 1795) = 0
fsync(4)= 0
close(4)= 0
munmap(0x7f32f849, 4096)= 0
rename(/var/lib/dpkg/updates/tmp.i, /var/lib/dpkg/updates/0011) = 0
open(/var/lib/dpkg/updates/, O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 4
fsync(4)= 0
close(4)= 0
open(/var/lib/dpkg/updates/tmp.i, O_WRONLY|O_CREAT|O_TRUNC, 0666) = 4
fcntl(4, F_GETFD) = 0
fcntl(4, F_SETFD, FD_CLOEXEC) = 0
fstat(4, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7f32f849
write(4, #padding\n#padding\n#padding\n#padd..., 4096) = 4096
write(4, padding\n#padding\n#padding\n#paddi..., 512) = 512
lseek(4, 0, SEEK_SET) = 0
stat(/etc/localtime, {st_mode=S_IFREG|0644, st_size=2819, ...}) = 0
write(6, 2011-05-05 13:21:58 status half-..., 63) = 63
write(4, Package: grub-pc\nStatus: install..., 1802) = 1802
ftruncate(4, 1802) = 0
fsync(4)= 0
close(4)= 0
munmap(0x7f32f849, 4096)= 0
rename(/var/lib/dpkg/updates/tmp.i, /var/lib/dpkg/updates/0012) = 0
open(/var/lib/dpkg/updates/, O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 4
fsync(4)= 0
close(4)= 0
open(/var/lib/dpkg/updates/tmp.i, O_WRONLY|O_CREAT|O_TRUNC, 0666) = 4
fcntl(4, F_GETFD) = 0
fcntl(4, F_SETFD, FD_CLOEXEC) = 0
fstat(4, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7f32f849
write(4, #padding\n#padding\n#padding\n#padd..., 4096) = 4096
write(4, padding\n#padding\n#padding\n#paddi..., 512) = 512
lseek(4, 0, SEEK_SET) = 0
stat(/var/lib/dpkg/info/grub-pc.postinst, {st_mode=S_IFREG|0755,
st_size=23003, ...}) = 0
clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD,
child_tidptr=0x7f32f8475a70) = 29950
rt_sigaction(SIGQUIT, {SIG_IGN, [], SA_RESTORER, 0x7f32f7d281e0}, {SIG_DFL, [],
SA_RESTORER, 0x7f32f7d281e0}, 8) = 0
rt_sigaction(SIGINT, {SIG_IGN, [], SA_RESTORER, 0x7f32f7d281e0}, {SIG_DFL, [],
SA_RESTORER, 0x7f32f7d281e0}, 8) = 0
wait4(29950, grub-probe: error: cannot stat `/dev/root'.
^C unfinished ...
-
/var/lib/dpkg/info/grub-pc.postinst is attached. I can't make sense of it.
BTW, I fixed the 'no space left on device' on the other machine with a btrfs
balance. No one seems to know this, but even though df reports that 64% of the
disk array is used, apparently one of the disks did get full somehow and was
preventing even a simple mkdir. But a balance fixed it.
I thought balancing was supposed to be automatic in BTRFS?
Is defrag not automatic?
On Thursday 5 May, 2011 12:55:44 you wrote:
Excerpts from CACook's message of 2011-05-05 15:50:02 -0400:
I was afraid of this finger-pointing.
We're not finger pointing, but we also don't maintain the script that is
failing. I'm happy to patch up bugs in the FS (or point you to newer
kernels that have them fixed) but at this point we don't have enough
info to say if it is an FS problem or a debian package problem.
Perhaps if you ran it under strace?
Other distros don't have problems with btrfs on /, so somehow this is
specific to debian's setup.
-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
grub-pc.postinst
Description: application/shellscript
Re: Having parent transid verify failed
Excerpts from Konstantinos Skarlatos's message of 2011-05-05 16:27:54 -0400: I think i made some progress. When i tried to remove the directory that i suspect contains the problematic file, i got this on the console rm -rf serverloft/ Ok, our one bad block is in the extent allocation tree. This is going to be the very hardest thing to fix. Until I finish off the code to rebuild parts of the extent allocation tree, I think your best bet is to copy the files off. The big question is, what happened to make this error? Can you describe your setup in more detail? -chris 2011 May 5 23:32:53 mail [ 200.580195] Oops: [#1] PREEMPT SMP 2011 May 5 23:32:53 mail [ 200.580220] last sysfs file: /sys/module/vt/parameters/default_utf8 2011 May 5 23:32:53 mail [ 200.581145] Stack: 2011 May 5 23:32:53 mail [ 200.581276] Call Trace: 2011 May 5 23:32:53 mail [ 200.581732] Code: cc 00 00 48 8d 91 28 e0 ff ff 48 89 e5 48 81 ec 90 00 00 00 48 89 5d d8 4c 89 65 e0 48 89 f3 4c 89 6d e8 4c 89 75 f0 4c 89 7d f8 48 8b 76 30 83 42 1c 01 48 b8 00 00 00 00 00 16 00 00 48 01 f0 2011 May 5 23:32:53 mail [ 200.583376] CR2: 0030 here is the part of dmesg that does not contain the thousands of parent transid verify failed messages May 5 23:32:51 mail kernel: [ 198.371084] parent transid verify failed on 3062073683968 wanted 5181 found 5188 May 5 23:32:51 mail kernel: [ 198.371204] parent transid verify failed on 3062073683968 wanted 5181 found 5188 May 5 23:32:53 mail kernel: [ 200.572774] Modules linked in: ipv6 btrfs zlib_deflate crc32c libcrc32c ext2 raid456 async_raid6_recov async_pq raid6_pq async_xor xor async_memcpy async_tx md_mod usb_storage uas snd_seq_dummy snd_seq_oss radeon snd_seq_midi_event ttm snd_seq snd_hda_codec_hdmi snd_seq_device drm_kms_helper ohci_hcd snd_hda_intel snd_hda_codec snd_pcm_oss snd_hwdep drm i2c_algo_bit snd_mixer_oss snd_pcm i2c_piix4 snd_timer snd soundcore snd_page_alloc ehci_hcd wmi i2c_core usbcore evdev processor button k10temp serio_raw pcspkr sg r8169 edac_core shpchp pci_hotplug edac_mce_amd mii sp5100_tco ext4 mbcache jbd2 crc16 sd_mod pata_acpi ahci libahci pata_atiixp libata scsi_mod May 5 23:32:53 mail kernel: [ 200.572808] Pid: 1037, comm: btrfs-transacti Not tainted 2.6.38-ARCH #1 May 5 23:32:53 mail kernel: [ 200.572810] Call Trace: May 5 23:32:53 mail kernel: [ 200.572817] [813a932b] ? __schedule_bug+0x59/0x5d May 5 23:32:53 mail kernel: [ 200.572820] [813af827] ? schedule+0x9f7/0xad0 May 5 23:32:53 mail kernel: [ 200.572823] [811e5827] ? generic_unplug_device+0x37/0x40 May 5 23:32:53 mail kernel: [ 200.572827] [a07ac164] ? md_raid5_unplug_device+0x64/0x110 [raid456] May 5 23:32:53 mail kernel: [ 200.572830] [a07ac223] ? raid5_unplug_queue+0x13/0x20 [raid456] May 5 23:32:53 mail kernel: [ 200.572833] [81012d79] ? read_tsc+0x9/0x20 May 5 23:32:53 mail kernel: [ 200.572837] [8108418c] ? ktime_get_ts+0xac/0xe0 May 5 23:32:53 mail kernel: [ 200.572840] [810e36c0] ? sync_page+0x0/0x50 May 5 23:32:53 mail kernel: [ 200.572842] [813af96e] ? io_schedule+0x6e/0xb0 May 5 23:32:53 mail kernel: [ 200.572844] [810e36fb] ? sync_page+0x3b/0x50 May 5 23:32:53 mail kernel: [ 200.572846] [813b0077] ? __wait_on_bit+0x57/0x80 May 5 23:32:53 mail kernel: [ 200.572848] [810e38c0] ? wait_on_page_bit+0x70/0x80 May 5 23:32:53 mail kernel: [ 200.572851] [8107a030] ? wake_bit_function+0x0/0x40 May 5 23:32:53 mail kernel: [ 200.572861] [a08348d2] ? read_extent_buffer_pages+0x412/0x480 [btrfs] May 5 23:32:53 mail kernel: [ 200.572867] [a0809e00] ? btree_get_extent+0x0/0x1b0 [btrfs] May 5 23:32:53 mail kernel: [ 200.572873] [a080ac7e] ? btree_read_extent_buffer_pages.isra.60+0x5e/0xb0 [btrfs] May 5 23:32:53 mail kernel: [ 200.572880] [a080c0bc] ? read_tree_block+0x3c/0x60 [btrfs] May 5 23:32:53 mail kernel: [ 200.572884] [a07f272b] ? read_block_for_search.isra.34+0x1fb/0x410 [btrfs] May 5 23:32:53 mail kernel: [ 200.572890] [a08417d1] ? btrfs_tree_unlock+0x51/0x60 [btrfs] May 5 23:32:53 mail kernel: [ 200.572895] [a07f5ca0] ? btrfs_search_slot+0x430/0xa30 [btrfs] May 5 23:32:53 mail kernel: [ 200.572900] [a07fb3a6] ? lookup_inline_extent_backref+0x96/0x460 [btrfs] May 5 23:32:53 mail kernel: [ 200.572904] [8112b8d3] ? kmem_cache_alloc+0x133/0x150 May 5 23:32:53 mail kernel: [ 200.572908] [a07fd452] ? __btrfs_free_extent+0xc2/0x6d0 [btrfs] May 5 23:32:53 mail kernel: [ 200.572914] [a0800f59] ? run_clustered_refs+0x389/0x830 [btrfs] May 5 23:32:53 mail kernel: [ 200.572920] [a084d900] ? btrfs_find_ref_cluster+0x10/0x190 [btrfs] May 5 23:32:53 mail kernel: [
Re: Cannot Deinstall a Debian Package
On Thu, May 5, 2011 at 2:32 PM, cac...@quantum-sci.com wrote: Here is the relevant section of strace: BTW, I fixed the 'no space left on device' on the other machine with a btrfs balance. No one seems to know this, but even though df reports that 64% of the disk array is used, apparently one of the disks did get full somehow and was preventing even a simple mkdir. But a balance fixed it. I thought balancing was supposed to be automatic in BTRFS? Is defrag not automatic? Could you include the information I asked for previously? (Kernel version, output of btrfs fi df and btrfs fi show) Defrag is not the same as balancing, and neither is quite the same as the balancing of the internal b-trees that make up the filesystem. Either way, this sounds like a bug that was fixed a few releases ago, but it's hard to say if that's the case without the requested information. Also, please place your replies below the original text, not above it. That's common practice on development mailing lists, and makes following the conversation much easier for others. http://www.catb.org/~esr/faqs/smart-questions.html may be a useful read as well. -- 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: Cannot Deinstall a Debian Package
On Thursday 5 May, 2011 13:31:17 cwillu wrote: I took the liberty of asking #debian, and they've requested that you file a bug in their bug tracker. They've also suggested that you might be able to short-circuit the faulty script in their kernel package via an exit 0, or even replace the faulty grub-probe by manually extracting the newer version of the package. I tried to install Debian's reportbug, but of course I can't. And assembling the info they need for email reporting will take me a half day of analysis. Part of the problem here is I am trying desperately to make a living in another line of business, and I don't have time for any of these problems. I don't know how to manually extract a package. I guess it's done with dpkg, but that will take more time for me to figure out. I've lost half of today already on this problem. -- 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: Having parent transid verify failed
On 5/5/2011 11:32 μμ, Chris Mason wrote: Excerpts from Konstantinos Skarlatos's message of 2011-05-05 16:27:54 -0400: I think i made some progress. When i tried to remove the directory that i suspect contains the problematic file, i got this on the console rm -rf serverloft/ Ok, our one bad block is in the extent allocation tree. This is going to be the very hardest thing to fix. Until I finish off the code to rebuild parts of the extent allocation tree, I think your best bet is to copy the files off. The big question is, what happened to make this error? Can you describe your setup in more detail? I created this btrfs filesystem on an arch linux system (amd64, quad core) with kernel 2.3.38.1. it is on top of a md raid 5. [root@linuxserver ~]# cat /proc/mdstat Personalities : [raid6] [raid5] [raid4] md0 : active raid5 sde1[3] sdc1[1] sda1[0] sdf1[4] 5860535808 blocks super 1.2 level 5, 512k chunk, algorithm 2 [4/4] [] the raid was grown from 3 devices to 4, and then btrfs was grown to max size. mount options were clear_cache,compress-force. I was investigating a performance issue that i had, because over the network i could only write to the filesystem at about 32mb/sec. when writing btrfs-delalloc- cpu usage was at 100%. While investigating i disabled compression, enabled space_cache and tried zlib compression, and various combinations, while copying large files back and forth using samba. BTW I tried to change some mount options using mount -o remount but although the new options were printed on dmesg i think that they were not enabled. I got the first error when i was copying some files and at the same time created a directory over samba. After a while i upgraded to 2.6.38.5 but nothing seems to have changed. I really dont think there is a hardware error here, but to be safe I am now running a check on the raid -chris 2011 May 5 23:32:53 mail [ 200.580195] Oops: [#1] PREEMPT SMP 2011 May 5 23:32:53 mail [ 200.580220] last sysfs file: /sys/module/vt/parameters/default_utf8 2011 May 5 23:32:53 mail [ 200.581145] Stack: 2011 May 5 23:32:53 mail [ 200.581276] Call Trace: 2011 May 5 23:32:53 mail [ 200.581732] Code: cc 00 00 48 8d 91 28 e0 ff ff 48 89 e5 48 81 ec 90 00 00 00 48 89 5d d8 4c 89 65 e0 48 89 f3 4c 89 6d e8 4c 89 75 f0 4c 89 7d f848 8b 76 30 83 42 1c 01 48 b8 00 00 00 00 00 16 00 00 48 01 f0 2011 May 5 23:32:53 mail [ 200.583376] CR2: 0030 here is the part of dmesg that does not contain the thousands of parent transid verify failed messages May 5 23:32:51 mail kernel: [ 198.371084] parent transid verify failed on 3062073683968 wanted 5181 found 5188 May 5 23:32:51 mail kernel: [ 198.371204] parent transid verify failed on 3062073683968 wanted 5181 found 5188 May 5 23:32:53 mail kernel: [ 200.572774] Modules linked in: ipv6 btrfs zlib_deflate crc32c libcrc32c ext2 raid456 async_raid6_recov async_pq raid6_pq async_xor xor async_memcpy async_tx md_mod usb_storage uas snd_seq_dummy snd_seq_oss radeon snd_seq_midi_event ttm snd_seq snd_hda_codec_hdmi snd_seq_device drm_kms_helper ohci_hcd snd_hda_intel snd_hda_codec snd_pcm_oss snd_hwdep drm i2c_algo_bit snd_mixer_oss snd_pcm i2c_piix4 snd_timer snd soundcore snd_page_alloc ehci_hcd wmi i2c_core usbcore evdev processor button k10temp serio_raw pcspkr sg r8169 edac_core shpchp pci_hotplug edac_mce_amd mii sp5100_tco ext4 mbcache jbd2 crc16 sd_mod pata_acpi ahci libahci pata_atiixp libata scsi_mod May 5 23:32:53 mail kernel: [ 200.572808] Pid: 1037, comm: btrfs-transacti Not tainted 2.6.38-ARCH #1 May 5 23:32:53 mail kernel: [ 200.572810] Call Trace: May 5 23:32:53 mail kernel: [ 200.572817] [813a932b] ? __schedule_bug+0x59/0x5d May 5 23:32:53 mail kernel: [ 200.572820] [813af827] ? schedule+0x9f7/0xad0 May 5 23:32:53 mail kernel: [ 200.572823] [811e5827] ? generic_unplug_device+0x37/0x40 May 5 23:32:53 mail kernel: [ 200.572827] [a07ac164] ? md_raid5_unplug_device+0x64/0x110 [raid456] May 5 23:32:53 mail kernel: [ 200.572830] [a07ac223] ? raid5_unplug_queue+0x13/0x20 [raid456] May 5 23:32:53 mail kernel: [ 200.572833] [81012d79] ? read_tsc+0x9/0x20 May 5 23:32:53 mail kernel: [ 200.572837] [8108418c] ? ktime_get_ts+0xac/0xe0 May 5 23:32:53 mail kernel: [ 200.572840] [810e36c0] ? sync_page+0x0/0x50 May 5 23:32:53 mail kernel: [ 200.572842] [813af96e] ? io_schedule+0x6e/0xb0 May 5 23:32:53 mail kernel: [ 200.572844] [810e36fb] ? sync_page+0x3b/0x50 May 5 23:32:53 mail kernel: [ 200.572846] [813b0077] ? __wait_on_bit+0x57/0x80 May 5 23:32:53 mail kernel: [ 200.572848] [810e38c0] ? wait_on_page_bit+0x70/0x80 May 5 23:32:53 mail kernel: [ 200.572851] [8107a030] ? wake_bit_function+0x0/0x40 May 5 23:32:53 mail kernel: [ 200.572861] [a08348d2] ? read_extent_buffer_pages+0x412/0x480 [btrfs] May 5 23:32:53
Re: Cannot Deinstall a Debian Package
On to, 2011-05-05 at 13:57 -0700, cac...@quantum-sci.com wrote: On Thursday 5 May, 2011 13:31:17 cwillu wrote: I took the liberty of asking #debian, and they've requested that you file a bug in their bug tracker. They've also suggested that you might be able to short-circuit the faulty script in their kernel package via an exit 0, or even replace the faulty grub-probe by manually extracting the newer version of the package. I tried to install Debian's reportbug, but of course I can't. And assembling the info they need for email reporting will take me a half day of analysis. Part of the problem here is I am trying desperately to make a living in another line of business, and I don't have time for any of these problems. I don't know how to manually extract a package. I guess it's done with dpkg, but that will take more time for me to figure out. I've lost half of today already on this problem. dpkg --fsys-tarfile foo.deb | tar -C / -tf - change -t to -x to actually extract -- 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: Cannot Deinstall a Debian Package
On Thu, May 5, 2011 at 2:57 PM, cac...@quantum-sci.com wrote: On Thursday 5 May, 2011 13:31:17 cwillu wrote: I took the liberty of asking #debian, and they've requested that you file a bug in their bug tracker. They've also suggested that you might be able to short-circuit the faulty script in their kernel package via an exit 0, or even replace the faulty grub-probe by manually extracting the newer version of the package. I tried to install Debian's reportbug, but of course I can't. And assembling the info they need for email reporting will take me a half day of analysis. Part of the problem here is I am trying desperately to make a living in another line of business, and I don't have time for any of these problems. I don't know how to manually extract a package. I guess it's done with dpkg, but that will take more time for me to figure out. I've lost half of today already on this problem. Okay, but do you see how your reaction hasn't endeared yourself to the people you're depending on to fix your problems for free? I'll note that this isn't the first time you've run into troubles with various raid systems, and you were even warned last december not to switch to btrfs as it wasn't mature enough for an end-user (even lacking a recovering fsck tool, which is still under development). In your position, you should be using ext4, with no raid, with a solid system of backups that you can recover from quickly and easily. Not experimenting with the latest shiny developments: that's something you do if you can afford to spend a few days on a regular basis fixing the latest exciting quirk. And when you run into problems, respectfully following the instructions given to you, including taking the advice of those who do this for a living, as opposed to issuing threats to besmirch a tool that wasn't ever marketed as being ready to use for the average joe who doesn't want to spend hours dealing with it. -- 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: Cannot Deinstall a Debian Package
On Thursday 5 May, 2011 13:40:25 cwillu wrote: Could you include the information I asked for previously? (Kernel version, output of btrfs fi df and btrfs fi show) Kernel 2.6.37-2 # btrfs fi df /home Data, RAID0: total=2.61TB, used=2.47TB Data: total=8.00MB, used=8.00MB System, RAID1: total=8.00MB, used=196.00KB System: total=4.00MB, used=0.00 Metadata, RAID1: total=6.88GB, used=4.64GB Metadata: total=8.00MB, used=0.00 # df /dev/sdb Filesystem 1K-blocks Used Available Use% Mounted on /dev/sdb 3907029168 2659716272 1242565920 69% /home # df /dev/sdc Filesystem 1K-blocks Used Available Use% Mounted on udev 1895384 268 1895116 1% /dev (this doesn't make any sense) # btrfs fi show failed to read /dev/sdg failed to read /dev/sdf failed to read /dev/sde failed to read /dev/sdd failed to read /dev/sr0 Label: none uuid: 85537aa8-30dc-4f87-ac55-6c8344304184 Total devices 2 FS bytes used 2.47TB devid1 size 1.82TB used 1.31TB path /dev/sdb devid2 size 1.82TB used 1.31TB path /dev/sdc Btrfs Btrfs v0.19 Defrag is not the same as balancing, and neither is quite the same as the balancing of the internal b-trees that make up the filesystem. I know they're not the same. But I am asking: I thought balancing was supposed to be automatic in BTRFS? Is defrag not automatic? No idea what 'balancing of the internal b-trees' is. -- 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: Cannot Deinstall a Debian Package
On Thursday 5 May, 2011 13:59:23 Lars Wirzenius wrote: dpkg --fsys-tarfile foo.deb | tar -C / -tf - I was expecting this to extract into the local directory, although it seems to have extracted into the final destinations. Can't be sure. grub-setup -V gives the new version. change -t to -x to actually extract I don't see the distinction. It does seem to have extracted. -- 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: Cannot Deinstall a Debian Package
On Thu, May 5, 2011 at 3:40 PM, cac...@quantum-sci.com wrote: On Thursday 5 May, 2011 13:40:25 cwillu wrote: Could you include the information I asked for previously? (Kernel version, output of btrfs fi df and btrfs fi show) Kernel 2.6.37-2 # btrfs fi df /home Data, RAID0: total=2.61TB, used=2.47TB Data: total=8.00MB, used=8.00MB System, RAID1: total=8.00MB, used=196.00KB System: total=4.00MB, used=0.00 Metadata, RAID1: total=6.88GB, used=4.64GB Metadata: total=8.00MB, used=0.00 # df /dev/sdb Filesystem 1K-blocks Used Available Use% Mounted on /dev/sdb 3907029168 2659716272 1242565920 69% /home # df /dev/sdc Filesystem 1K-blocks Used Available Use% Mounted on udev 1895384 268 1895116 1% /dev (this doesn't make any sense) # btrfs fi show failed to read /dev/sdg failed to read /dev/sdf failed to read /dev/sde failed to read /dev/sdd failed to read /dev/sr0 Label: none uuid: 85537aa8-30dc-4f87-ac55-6c8344304184 Total devices 2 FS bytes used 2.47TB devid 1 size 1.82TB used 1.31TB path /dev/sdb devid 2 size 1.82TB used 1.31TB path /dev/sdc Btrfs Btrfs v0.19 Defrag is not the same as balancing, and neither is quite the same as the balancing of the internal b-trees that make up the filesystem. I know they're not the same. But I am asking: I thought balancing was supposed to be automatic in BTRFS? Is defrag not automatic? Fair enough. Btrfs works mostly like ext in this sense: the way it reads and writes data generally avoids fragmentation. There are some issues in this area still, but they're not the cause of no-space problems typically, rather they tend to cause performance loss. A balance operation is more about balancing the space use of the large allocations btrfs makes from its pool of free disk-space to one of the block groups that holds data or metadata. mkdir failing while you still have lots of disk space free would typically mean something along the lines of: all the free disk space has been allocated to either the metadata or data block groups, and the metadata block groups are full. This sort of behaviour has mostly gone away in the last couple releases, although it would take a balance operation (as you performed) to get everything working right. How old was the filesystem? It might just have been lingering problems from an older kernel, which would be cleared up entirely by the balance you just ran. -- 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: Cannot Deinstall a Debian Package
On Thu, May 5, 2011 at 3:48 PM, cac...@quantum-sci.com wrote: On Thursday 5 May, 2011 13:59:23 Lars Wirzenius wrote: dpkg --fsys-tarfile foo.deb | tar -C / -tf - I was expecting this to extract into the local directory, although it seems to have extracted into the final destinations. Can't be sure. grub-setup -V gives the new version. change -t to -x to actually extract I don't see the distinction. It does seem to have extracted. tar -t just lists the contents, -x actually does an extract. It's plausible that the update you attempted before did actually unpack the files to their locations, and only failed to run the post-install scripts. -- 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
Converting 1-drive ext4 to 4-drive raid10 btrfs
Hello! I have a 1 TB ext4 drive that's quite full (~50 GB free space, though I could free up another 100 GB or so if necessary) and two empty 0.5 TB drives. Is it possible to get another 1 TB drive and combine the four drives to a btrfs raid10 setup without (if all goes well) losing my data? Regards, Paul -- 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: Converting 1-drive ext4 to 4-drive raid10 btrfs
On Thu, May 05, 2011 at 05:01:04PM -0400, Paul Schroeder wrote: I have a 1 TB ext4 drive that's quite full (~50 GB free space, though I could free up another 100 GB or so if necessary) and two empty 0.5 TB drives. Is it possible to get another 1 TB drive and combine the four drives to a btrfs raid10 setup without (if all goes well) losing my data? Not at the moment. You'd have to be able to change RAID levels for your FS configuration, which isn't implemented yet. It's planned, but nobody's got round to it yet. (I'll probably start looking at it as my next btrfs patch, if nobody else gets there first). Hugo. -- === Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk === PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk --- Your problem is that you have a negative personality. --- No, I don't! signature.asc Description: Digital signature
Re: btrfs seed with luks encrypted devices
On 05/03/2011 06:50 PM, cwillu wrote: On Tue, May 3, 2011 at 7:32 PM, Geoff Rittergeoff.rit...@gmail.com wrote: Not sure where to report bugs or even find a coherent list of them. Sorry if this is already well known. When attempting to use an unlocked encrypted device as either a seed device or the writeable device, a kernel bug will be displayed at fs/btrfs/volumes.c:2402 after attempting to add the writeable device to the mounted read-only seed. STR: 1. cryptsetup luksFormat /dev/sdx1 2. cryptsetup luksOpen /dev/sdx1 luksSeed 3. mkfs.btrfs /dev/mapper/luksSeed 4. mount and add files if you want, then unmount 5. btrfstune -S 1 /dev/mapper/luksSeed 6. mount /dev/mapper/luksSeed /mnt/luksSeed 7. btrfs device add /dev/sdx2 /mnt/luksSeed 8. Observe kernel BUG. I would hope to expect to see an error message if this is never intended to be possible. But normal btrfs file systems appear to function normally under both encrypted and lvm partitions. This attached kernel message was from two LVM logical volumes on a luks encrypted partition. However, I also tested this with two regular partitions between endrypted-seed/unencrypted-rw, endrypted-rw/unencrypted-seed, and both encrypted. [ cut here ] kernel BUG at fs/btrfs/volumes.c:2402! invalid opcode: [#1] SMP last sysfs file: /sys/devices/pci:00/:00:05.0/host0/target0:0:0/0:0:0:0/block/sda/dev CPU 0 Modules linked in: usbhid parport_pc hid firewire_ohci i2c_nforce2 firewire_core i2c_core forcedeth parport Pid: 1845, comm: btrfs Not tainted 2.6.37.6 #3 System manufacturer System Product Name/M2N-SLI DELUXE RIP: 0010:[8149cdba] [8149cdba] __finish_chunk_alloc+0x21a/0x220 RSP: 0018:880175533668 EFLAGS: 00010286 RAX: ffe4 RBX: 880176004500 RCX: 0040 RDX: RSI: ea000523aff0 RDI: 88017788df00 RBP: 8801755336e8 R08: bda5 R09: R10: R11: ffe4 R12: 880177e8e000 R13: 880176956b00 R14: 8801773cb000 R15: 0070 FS: 7fe05f784760() GS:8800bfc0() knlGS: CS: 0010 DS: ES: CR0: 8005003b CR2: 00683a10 CR3: 00017549c000 CR4: 06f0 DR0: DR1: DR2: DR3: DR6: 0ff0 DR7: 0400 Process btrfs (pid: 1845, threadinfo 880175532000, task 88017547ed00) Stack: 1000 8801 0800 00030a40 8801773cc000 0800 8801770ef810 8801770ef810 1910 8800bfd119ff 8801773cb000 Call Trace: [8149f18e] btrfs_alloc_chunk+0x8e/0xa0 [814647ee] do_chunk_alloc+0x14e/0x2a0 [814685f2] btrfs_reserve_extent+0xd2/0x180 [81468bb1] btrfs_alloc_free_block+0xc1/0x330 [8145696d] __btrfs_cow_block+0x14d/0x610 [81456f3f] btrfs_cow_block+0x10f/0x200 [8145bfaa] btrfs_search_slot+0x50a/0x880 [81455f5a] ? btrfs_free_path+0x2a/0x40 [8145d38e] btrfs_insert_empty_items+0x7e/0xe0 [8146efa7] btrfs_insert_empty_inode+0x37/0x40 [814b554f] create_reloc_inode.clone.41+0x9f/0x230 [81113257] ? kmem_cache_alloc+0xb7/0x110 [814bb91b] btrfs_relocate_block_group+0x14b/0x2e0 [8149bf03] btrfs_relocate_chunk.clone.41+0x83/0x5b0 [8149a180] ? map_extent_buffer+0xb0/0xc0 [814890f5] ? btrfs_chunk_type+0xe5/0xf0 [814a0b6b] btrfs_init_new_device+0xaeb/0xd00 [814a6476] ? btrfs_ioctl+0x496/0x9d0 [814a6498] btrfs_ioctl+0x4b8/0x9d0 [8102a0a4] ? do_page_fault+0x1a4/0x3d0 [8113002d] do_vfs_ioctl+0x9d/0x580 [811339fe] ? dput+0x7e/0x160 [811211a2] ? fput+0x192/0x250 [81130591] sys_ioctl+0x81/0xa0 [81002a2b] system_call_fastpath+0x16/0x1b Code: ef e8 eb 5e c7 ff 48 83 c4 58 31 c0 5b 41 5c 41 5d 41 5e 41 5f c9 c3 48 83 c4 58 b8 f4 ff ff ff 5b 41 5c 41 5d 41 5e 41 5f c9 c30f 0b 0f 0b 0f 0b 55 48 89 e5 41 57 41 56 41 55 41 54 53 48 83 RIP [8149cdba] __finish_chunk_alloc+0x21a/0x220 RSP880175533668 ---[ end trace 8fa94cbaf8bdef31 ]--- Can you try again using the latest 2.6.39rc? This is a enospc-related error (RAX: ffe4), and a bunch of those have been fixed since 2.6.37. 2.6.39-rc5 - unpatched apparently just before they took down the 'full source' link and a get of the btrfs-progs source from today 20110503. Still produces an issue and fails... However, the issue appears to be somewhere else. I might have to re run the tests on the encrypted lvms and other combination. Here are the results for an unencrypted normal Seed partition with encrypted rewritable
Re: Cannot Deinstall a Debian Package
On Thursday 5 May, 2011 14:48:49 cwillu wrote: How old was the filesystem? It might just have been lingering problems from an older kernel, which would be cleared up entirely by the balance you just ran. I specifically set up the filesystem with the Live CD of the M- release of Ubuntu, so as to be using a much newer kernel than Debian's. This was in December. Then I used the Debian net install CD in Expert mode to install the OS. I took all pains to be using the newest OS available to set up the disks, so as to take advantage of WD's Advanced Format, and the newest improvements to BTRFS. But the balance is still going after more than an hour. I am seeing drastically conflicting info from df and btrfs filesystem df, which is inexplicable. -- 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: Cannot Deinstall a Debian Package
On Thu, May 5, 2011 at 6:33 PM, cac...@quantum-sci.com wrote: On Thursday 5 May, 2011 14:48:49 cwillu wrote: How old was the filesystem? It might just have been lingering problems from an older kernel, which would be cleared up entirely by the balance you just ran. I specifically set up the filesystem with the Live CD of the M- release of Ubuntu, so as to be using a much newer kernel than Debian's. This was in December. Then I used the Debian net install CD in Expert mode to install the OS. I took all pains to be using the newest OS available to set up the disks, so as to take advantage of WD's Advanced Format, and the newest improvements to BTRFS. But the balance is still going after more than an hour. I am seeing drastically conflicting info from df and btrfs filesystem df, which is inexplicable. https://btrfs.wiki.kernel.org/index.php/FAQ#Why_does_df_show_incorrect_free_space_for_my_RAID_volume.3F The above link may help explain why df and btrfs fi df differ. -- 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: btrfs seed with luks encrypted devices
Excerpts from cwillu's message of 2011-05-03 21:50:53 -0400: On Tue, May 3, 2011 at 7:32 PM, Geoff Ritter geoff.rit...@gmail.com wrote: Not sure where to report bugs or even find a coherent list of them. Sorry if this is already well known. When attempting to use an unlocked encrypted device as either a seed device or the writeable device, a kernel bug will be displayed at fs/btrfs/volumes.c:2402 after attempting to add the writeable device to the mounted read-only seed. STR: 1. cryptsetup luksFormat /dev/sdx1 2. cryptsetup luksOpen /dev/sdx1 luksSeed 3. mkfs.btrfs /dev/mapper/luksSeed 4. mount and add files if you want, then unmount 5. btrfstune -S 1 /dev/mapper/luksSeed 6. mount /dev/mapper/luksSeed /mnt/luksSeed 7. btrfs device add /dev/sdx2 /mnt/luksSeed 8. Observe kernel BUG. I would hope to expect to see an error message if this is never intended to be possible. But normal btrfs file systems appear to function normally under both encrypted and lvm partitions. This attached kernel message was from two LVM logical volumes on a luks encrypted partition. However, I also tested this with two regular partitions between endrypted-seed/unencrypted-rw, endrypted-rw/unencrypted-seed, and both encrypted. Ok, looks like I busted the seed support when I fixed up some of the chunk allocations. I'll reproduce this and work out a fix. -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: Having parent transid verify failed
Excerpts from Konstantinos Skarlatos's message of 2011-05-05 17:04:00 -0400: On 5/5/2011 11:32 μμ, Chris Mason wrote: Excerpts from Konstantinos Skarlatos's message of 2011-05-05 16:27:54 -0400: I think i made some progress. When i tried to remove the directory that i suspect contains the problematic file, i got this on the console rm -rf serverloft/ Ok, our one bad block is in the extent allocation tree. This is going to be the very hardest thing to fix. Until I finish off the code to rebuild parts of the extent allocation tree, I think your best bet is to copy the files off. The big question is, what happened to make this error? Can you describe your setup in more detail? I created this btrfs filesystem on an arch linux system (amd64, quad core) with kernel 2.3.38.1. it is on top of a md raid 5. [root@linuxserver ~]# cat /proc/mdstat Personalities : [raid6] [raid5] [raid4] md0 : active raid5 sde1[3] sdc1[1] sda1[0] sdf1[4] 5860535808 blocks super 1.2 level 5, 512k chunk, algorithm 2 [4/4] [] the raid was grown from 3 devices to 4, and then btrfs was grown to max size. mount options were clear_cache,compress-force. I was investigating a performance issue that i had, because over the network i could only write to the filesystem at about 32mb/sec. when writing btrfs-delalloc- cpu usage was at 100%. While investigating i disabled compression, enabled space_cache and tried zlib compression, and various combinations, while copying large files back and forth using samba. BTW I tried to change some mount options using mount -o remount but although the new options were printed on dmesg i think that they were not enabled. I got the first error when i was copying some files and at the same time created a directory over samba. After a while i upgraded to 2.6.38.5 but nothing seems to have changed. I really dont think there is a hardware error here, but to be safe I am now running a check on the raid This error basically means we didn't write the block. It could be because the write went to the wrong spot, or the hardware stack messed it up, or because of a btrfs bug. But, 2.6.38 is relatively recent. It doesn't look like memory corruption because the transids are fairly close. When you grew the raid device, did you grow a partition as well? We've had trouble in the past with block dev flushing code kicking in as devices are resized. Samba isn't doing anything exotic, and 2.6.38 has my recent fixes for rare metadata corruption bugs in btrfs. -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: Having parent transid verify failed
Chris Mason wrote: We've had trouble in the past with block dev flushing code kicking in as devices are resized. Might this be the problem with my root node? I wish my problem was in only one directory. :) //Peter -- 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: fix extra metadata chunk allocation in --mixed case
On 05/05/2011 10:16 PM, Arne Jansen wrote:
When creating a mixed fs with mkfs, an extra metadata chunk got allocated.
This is because btrfs_reserve_extent calls do_chunk_alloc for METADATA,
which in turn wasn't able to find the proper space_info, as __find_space_info
did a hard compare of the flags. It is now sufficient for the space_info to
include the proper flag. This reflects the change done to the kernel code
to support mixed chunks.
Also for a subsequent chunk allocation (which should not be hit in the mkfs
case), the chunk is now created with the flags from the space_info instead
of the requested flags. A better solution would be to pull the full changeset
for the mixed case from the kernel into the user mode (or, even better, share
the code)
The additional chunk probably confused block_rsv calculation, which in turn
led to severeal ENOSPC Oopses.
Good catch!
Reviewed-by: Liu Bo liubo2...@cn.fujitsu.com
Signed-off-by: Arne Jansen sensi...@gmx.net
---
extent-tree.c |7 ---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/extent-tree.c b/extent-tree.c
index b2f9bb2..c6c77c6 100644
--- a/extent-tree.c
+++ b/extent-tree.c
@@ -1735,7 +1735,7 @@ static struct btrfs_space_info
*__find_space_info(struct btrfs_fs_info *info,
struct btrfs_space_info *found;
list_for_each(cur, head) {
found = list_entry(cur, struct btrfs_space_info, list);
- if (found-flags == flags)
+ if (found-flags flags)
return found;
}
return NULL;
@@ -1812,7 +1812,8 @@ static int do_chunk_alloc(struct btrfs_trans_handle
*trans,
thresh)
return 0;
- ret = btrfs_alloc_chunk(trans, extent_root, start, num_bytes, flags);
+ ret = btrfs_alloc_chunk(trans, extent_root, start, num_bytes,
+ space_info-flags);
if (ret == -ENOSPC) {
space_info-full = 1;
return 0;
@@ -1820,7 +1821,7 @@ static int do_chunk_alloc(struct btrfs_trans_handle
*trans,
BUG_ON(ret);
- ret = btrfs_make_block_group(trans, extent_root, 0, flags,
+ ret = btrfs_make_block_group(trans, extent_root, 0, space_info-flags,
BTRFS_FIRST_CHUNK_TREE_OBJECTID, start, num_bytes);
BUG_ON(ret);
return 0;
--
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
[RFC PATCH] Btrfs: do not flush csum items of unchanged file data during treelog
The current code relogs the entire inode every time during fsync log,
and it is much better suited to small files rather than large ones.
During my performance test, the fsync performace of large files sucks,
and we can ascribe this to the tremendous amount of csum infos of the
large ones, cause we have to flush all of these csum infos into log trees
even when there are only _one_ change in the whole file data. Apparently,
to optimize fsync, we need to create a filter to skip the unnecessary csum
ones, that is, the corresponding file data remains unchanged before this fsync.
Here I have some test results to show, I use sysbench to do random write +
fsync.
===
sysbench --test=fileio --num-threads=1 --file-num=2 --file-block-size=4K
--file-total-size=8G --file-test-mode=rndwr --file-io-mode=sync
--file-extra-flags= [prepare, run]
===
Sysbench args:
- Number of threads: 1
- Extra file open flags: 0
- 2 files, 4Gb each
- Block size 4Kb
- Number of random requests for random IO: 1
- Read/Write ratio for combined random IO test: 1.50
- Periodic FSYNC enabled, calling fsync() each 100 requests.
- Calling fsync() at the end of test, Enabled.
- Using synchronous I/O mode
- Doing random write test
Sysbench results:
===
Operations performed: 0 Read, 1 Write, 200 Other = 10200 Total
Read 0b Written 39.062Mb Total transferred 39.062Mb
===
a) without patch: (*SPEED* : 451.01Kb/sec)
112.75 Requests/sec executed
b) with patch: (*SPEED* : 4.7533Mb/sec)
1216.84 Requests/sec executed
PS: I've made a _sub transid_ stuff patch, but it does not perform as
effectively as this patch,
and I'm wanderring where the problem is and trying to improve it more.
Signed-off-by: Liu Bo liubo2...@cn.fujitsu.com
---
fs/btrfs/tree-log.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/fs/btrfs/tree-log.c b/fs/btrfs/tree-log.c
index c50271a..b934a36 100644
--- a/fs/btrfs/tree-log.c
+++ b/fs/btrfs/tree-log.c
@@ -2662,6 +2662,9 @@ static noinline int copy_items(struct btrfs_trans_handle
*trans,
extent = btrfs_item_ptr(src, start_slot + i,
struct btrfs_file_extent_item);
+ if (btrfs_file_extent_generation(src, extent)
trans-transid)
+ continue;
+
found_type = btrfs_file_extent_type(src, extent);
if (found_type == BTRFS_FILE_EXTENT_REG ||
found_type == BTRFS_FILE_EXTENT_PREALLOC) {
--
1.6.5.2
--
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: Cannot Deinstall a Debian Package
Hallo, Cacook, Du meintest am 05.05.11: I took all pains to be using the newest OS available to set up the disks, so as to take advantage of WD's Advanced Format, and the newest improvements to BTRFS. But the balance is still going after more than an hour. Where's the problem? Balancing 4 TByte can need some hours. Maybe it needs more than 1 day. It was mentioned again some (few) weeks ago. Take a look at the last lines of dmesg, every hour. Then you can estimate how long you have to wait. Viele Gruesse! Helmut -- 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: Having parent transid verify failed
On 6/5/2011 2:50 πμ, Chris Mason wrote: Excerpts from Konstantinos Skarlatos's message of 2011-05-05 17:04:00 -0400: On 5/5/2011 11:32 μμ, Chris Mason wrote: Excerpts from Konstantinos Skarlatos's message of 2011-05-05 16:27:54 -0400: I think i made some progress. When i tried to remove the directory that i suspect contains the problematic file, i got this on the console rm -rf serverloft/ Ok, our one bad block is in the extent allocation tree. This is going to be the very hardest thing to fix. Until I finish off the code to rebuild parts of the extent allocation tree, I think your best bet is to copy the files off. The big question is, what happened to make this error? Can you describe your setup in more detail? I created this btrfs filesystem on an arch linux system (amd64, quad core) with kernel 2.3.38.1. it is on top of a md raid 5. [root@linuxserver ~]# cat /proc/mdstat Personalities : [raid6] [raid5] [raid4] md0 : active raid5 sde1[3] sdc1[1] sda1[0] sdf1[4] 5860535808 blocks super 1.2 level 5, 512k chunk, algorithm 2 [4/4] [] the raid was grown from 3 devices to 4, and then btrfs was grown to max size. mount options were clear_cache,compress-force. I was investigating a performance issue that i had, because over the network i could only write to the filesystem at about 32mb/sec. when writing btrfs-delalloc- cpu usage was at 100%. While investigating i disabled compression, enabled space_cache and tried zlib compression, and various combinations, while copying large files back and forth using samba. BTW I tried to change some mount options using mount -o remount but although the new options were printed on dmesg i think that they were not enabled. I got the first error when i was copying some files and at the same time created a directory over samba. After a while i upgraded to 2.6.38.5 but nothing seems to have changed. I really dont think there is a hardware error here, but to be safe I am now running a check on the raid This error basically means we didn't write the block. It could be because the write went to the wrong spot, or the hardware stack messed it up, or because of a btrfs bug. But, 2.6.38 is relatively recent. It doesn't look like memory corruption because the transids are fairly close. When you grew the raid device, did you grow a partition as well? We've had trouble in the past with block dev flushing code kicking in as devices are resized. no, I did not grow any partitions, I just added one disk to the Raid 5 md0 device, and then grew the btrfs filesystem to max size(no partitions on md0). I can remember that as a test (to see if shrink works) i shrank the fs by 1 gb and then grew it again to max size. Samba isn't doing anything exotic, and 2.6.38 has my recent fixes for rare metadata corruption bugs in btrfs. -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
