summaryrefslogtreecommitdiff
path: root/stun.h
blob: e16c3e7abb7b423b97ae3512b3d4cf09a30cc97e (plain)
1
2
3
4
5
6
#ifndef STUN_H
#define STUN_H

extern int print_stun_probe(char *server, int sport, int tport);

#endif /* STUN_H */
td class='label'>space:mode:
authorWang Xiaoguang <wangxg.fnst@cn.fujitsu.com>2016-09-02 10:58:46 +0800
committerDavid Sterba <dsterba@suse.com>2016-09-06 16:31:43 +0200
commitce129655c9d9aaa7b3bcc46529db1b36693575ed (patch)
tree3e653a3c55e2393f04ebc881712921f35cf3eb2b
parented7a6948394305b810d0c6203268648715e5006f (diff)
btrfs: introduce tickets_id to determine whether asynchronous metadata reclaim work makes progress
In btrfs_async_reclaim_metadata_space(), we use ticket's address to determine whether asynchronous metadata reclaim work is making progress. ticket = list_first_entry(&space_info->tickets, struct reserve_ticket, list); if (last_ticket == ticket) { flush_state++; } else { last_ticket = ticket; flush_state = FLUSH_DELAYED_ITEMS_NR; if (commit_cycles) commit_cycles--; } But indeed it's wrong, we should not rely on local variable's address to do this check, because addresses may be same. In my test environment, I dd one 168MB file in a 256MB fs, found that for this file, every time wait_reserve_ticket() called, local variable ticket's address is same, For above codes, assume a previous ticket's address is addrA, last_ticket is addrA. Btrfs_async_reclaim_metadata_space() finished this ticket and wake up it, then another ticket is added, but with the same address addrA, now last_ticket will be same to current ticket, then current ticket's flush work will start from current flush_state, not initial FLUSH_DELAYED_ITEMS_NR, which may result in some enospc issues(I have seen this in my test machine). Signed-off-by: Wang Xiaoguang <wangxg.fnst@cn.fujitsu.com> Reviewed-by: Josef Bacik <jbacik@fb.com> Signed-off-by: David Sterba <dsterba@suse.com>
Diffstat