search for: max_key

...ent too): --- ulogd-2.0.3.orig/filter/ulogd_filter_IP2BIN.c 2013-06-18 16:52:50.269920891 -0400 +++ ulogd-2.0.3/filter/ulogd_filter_IP2BIN.c 2014-01-29 10:49:37.641807142 -0500 @@ -205,7 +205,7 @@ int fret; /* Iter on all addr fields */ - for(i = START_KEY; i < MAX_KEY; i++) { + for(i = START_KEY; i <= MAX_KEY; i++) { if (pp_is_valid(inp, i)) { fret = ip2bin(inp, i, i-START_KEY); if (fret != ULOGD_IRET_OK) -- Configure bugmail: https://bugzilla.netfilter.org/userprefs.cgi?tab=email -------...

...de, } } - key.objectid = sk->min_objectid; - key.type = sk->min_type; - key.offset = sk->min_offset; + key.objectid = max(sk->start_objectid, sk->min_objectid); + key.type = max(sk->start_type,sk->min_type); + key.offset = max(sk->start_offset, sk->min_offset); max_key.objectid = sk->max_objectid; max_key.type = sk->max_type; @@ -1207,6 +1207,11 @@ static noinline int search_ioctl(struct inode *inode, } ret = 0; err: + /* save the key for an hypothetic next iteration */ + sk->start_objectid = key.objectid; + sk->start_type = key.type; + sk->...

This series introduces a generic readahead interface for btrfs trees. The intention is to use it to speed up scrub in a first run, but balance is another hot candidate. In general, every tree walk could be accompanied by a readahead. Deletion of large files comes to mind, where the fetching of the csums takes most of the time. Also the initial build-ups of free-space-caches and

...xtent = offset + len; + } + /* + * Need to let the callers know we dropped the path so they should + * re-search. + */ + if (!ret && need_find_last_extent) + ret = 1; return ret; } @@ -3624,6 +3769,7 @@ static int btrfs_log_inode(struct btrfs_trans_handle *trans, struct btrfs_key max_key; struct btrfs_root *log = root->log_root; struct extent_buffer *src = NULL; + u64 last_extent = 0; int err = 0; int ret; int nritems; @@ -3738,11 +3884,15 @@ again: goto next_slot; } - ret = copy_items(trans, inode, dst_path, src, ins_start_slot, - ins_nr, inode_only); -...

This series introduces a generic readahead interface for btrfs trees. The intention is to use it to speed up scrub in a first run, but balance is another hot candidate. In general, every tree walk could be accompanied by a readahead. Deletion of large files comes to mind, where the fetching of the csums takes most of the time. Also the initial build-ups of free-space-caches and

Hi Linus, My for-linus branch has a one line fix: git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git for-linus Sage hit a deadlock with ceph on btrfs, and Josef tracked it down to a regression in our initial rc1 pull. When doing nocow writes we were sometimes starting a transaction with locks held. Josef Bacik (1) commits (+1/-0): Btrfs: release path before starting

I''ve been working to try to improve the write-ahead log''s performance, and I found that the bottleneck addresses in the checksum items, especially when we want to make a random write on a large file, e.g a 4G file. Then a idea for this suggested by Chris is to use sub transaction ids and just to log the part of inode that had changed since either the last log commit or the last