search for: map_private_extent_buff

...6gh4k0zl2t5zq/btrfs_hangs_3-4-6.log It starts like this: Oct 30 22:42:36 localhost kernel: btrfs bad mapping eb start 982689189888 len 4096, wanted 4424 17 Oct 30 22:42:36 localhost kernel: ------------[ cut here ]------------ Oct 30 22:42:36 localhost kernel: WARNING: at fs/btrfs/extent_io.c:4661 map_private_extent_buffer+0x83/0xc9() Oct 30 22:42:36 localhost kernel: Hardware name: A780L3L Oct 30 22:42:36 localhost kernel: Modules linked in: hwmon_vid snd_hda_codec_hdmi nvidia(PO) snd_hda_codec_realtek snd_hda_intel snd_hda_codec i2c_piix4 k10temp Oct 30 22:42:36 localhost kernel: Pid: 7143, comm: btrfs-endio-wri...

...ge+0xb/0xb [172816.293045] ---[ end trace 095cf6945c90cf63 ]--- [172816.293046] btrfs unable to find ref byte nr 1871181426688 parent 0 root 2 owner 0 offset 0 [172816.293050] BUG: unable to handle kernel NULL pointer dereference at (null) [172816.293054] IP: [<ffffffff81148998>] map_private_extent_buffer+0x9/0xde [172816.293057] PGD 0 [172816.293058] Oops: 0000 [#1] SMP [172816.293060] CPU 1 [172816.293061] Modules linked in: zram(C) af_packet fuse snd_seq_oss snd_seq_midi_event snd_seq snd_pcm_oss snd_mixer_oss nls_iso8859_15 nls_cp437 vfat fat reiserfs loop nfs tcp_cubic lockd auth_rpcgss...

...rection = path->reada; struct extent_buffer *eb; u32 nr; @@ -1256,6 +1257,15 @@ static void reada_for_search(struct btrfs_root *root, nritems = btrfs_header_nritems(node); nr = slot; while (1) { + if (!node->map_token) { + unsigned long offset = btrfs_node_key_ptr_offset(nr); + map_private_extent_buffer(node, offset, + sizeof(struct btrfs_key_ptr), + &node->map_token, + &node->kaddr, + &node->map_start, + &node->map_len, KM_USER1); + } if (direction < 0) { if (nr == 0) break; @@ -1273,14 +1283,23 @@ static void reada_...

...he entire extent buffer, otherwise callers can''t access + * all keys/items of the leaf/node. Specially needed for case + * where leaf/node size is greater than page cache size. + */ + while (len_left > 0) { + unsigned long len = min(PAGE_CACHE_SIZE, len_left); + int err; + + err = map_private_extent_buffer(b, eb_offset, len, &kaddr, + &map_start, &map_len); + len_left -= len; + eb_offset += len; + if (k) + continue; + if (!err) { + k = (struct btrfs_disk_key *)(kaddr + offset - + map_start); + } else { + read_extent_buffer(b, &unaligned, + offset, s...

...@@ -4606,7 +5071,7 @@ int read_extent_buffer_pages(struct extent_io_tree *tree, } } if (all_uptodate) { - if (start_i == 0) + if (start_i == 0 && eb->len >= PAGE_SIZE) set_bit(EXTENT_BUFFER_UPTODATE, &eb->bflags); goto unlock_exit; } @@ -4693,7 +5158,7 @@ int map_private_extent_buffer(struct extent_buffer *eb, unsigned long start, unsigned long *map_start, unsigned long *map_len) { - size_t offset = start & (PAGE_CACHE_SIZE - 1); + size_t offset; char *kaddr; struct page *p; size_t start_offset = eb->start & ((u64)PAGE_CACHE_SIZE - 1); @...

With the ATI bug I was hitting earlier fixed, only my btrfs partition continues to show high cpu usage for some operations. Rsync, git pull, git checkout and svn up are typicall operations which trigger the high cpu usage. As an example, this perf report is from using git checkout to change to a new branch; the change needed to checkout 208 files out of about 1600 total files. du(1) reports

...0 14:57:17 mithrandir kernel: [ 266.181986] [<ffffffffa0221862>] __btrfs_free_extent+0x24b/0x54f [btrfs] Jun 10 14:57:17 mithrandir kernel: [ 266.182042] [<ffffffff8139e63a>] ? _raw_spin_unlock+0x1e/0x29 Jun 10 14:57:17 mithrandir kernel: [ 266.182105] [<ffffffffa024ec12>] ? map_private_extent_buffer+0xaa/0xcd [btrfs] Jun 10 14:57:17 mithrandir kernel: [ 266.182174] [<ffffffffa0223d36>] run_clustered_refs+0x616/0x660 [btrfs] Jun 10 14:57:17 mithrandir kernel: [ 266.182228] [<ffffffff8139e63a>] ? _raw_spin_unlock+0x1e/0x29 Jun 10 14:57:17 mithrandir kernel: [ 266.182290] [&lt...

An user reported that he has hit an annoying deadlock while playing with ceph based on btrfs. Current updating device tree requires space from METADATA chunk, so we -may- need to do a recursive chunk allocation when adding/updating dev extent, that is where the deadlock comes from. If we use SYSTEM metadata to update device tree, we can avoid the recursive stuff. Reported-by: Jim Schutt

For quite a while, I''ve experienced oddities with snapshotted Firefox _CACHE_00?_ files, whose checksums (and contents) would change after the btrfs snapshot was taken, and would even change depending on how the file was brought to memory (e.g., rsyncing it to backup storage vs checking its md5sum before or after the rsync). This only affected these cache files, so I didn''t give