Searched hist:c6b305a89b1903d63652691ad5eb9f05aa0326b8 (Results 1 – 3 of 3) sorted by relevance
/openbmc/linux/fs/btrfs/ |
H A D | transaction.h | diff c6b305a89b1903d63652691ad5eb9f05aa0326b8 Tue Dec 18 08:16:16 CST 2012 Josef Bacik <jbacik@fusionio.com> Btrfs: don't re-enter when allocating a chunk
If we start running low on metadata space we will try to allocate a chunk, which could then try to allocate a chunk to add the device entry. The thing is we allocate a chunk before we try really hard to make the allocation, so we should be able to find space for the device entry. Add a flag to the trans handle so we know we're currently allocating a chunk so we can just bail out if we try to allocate another chunk. Thanks,
Signed-off-by: Josef Bacik <jbacik@fusionio.com>
|
H A D | transaction.c | diff c6b305a89b1903d63652691ad5eb9f05aa0326b8 Tue Dec 18 08:16:16 CST 2012 Josef Bacik <jbacik@fusionio.com> Btrfs: don't re-enter when allocating a chunk
If we start running low on metadata space we will try to allocate a chunk, which could then try to allocate a chunk to add the device entry. The thing is we allocate a chunk before we try really hard to make the allocation, so we should be able to find space for the device entry. Add a flag to the trans handle so we know we're currently allocating a chunk so we can just bail out if we try to allocate another chunk. Thanks,
Signed-off-by: Josef Bacik <jbacik@fusionio.com>
|
H A D | extent-tree.c | diff c6b305a89b1903d63652691ad5eb9f05aa0326b8 Tue Dec 18 08:16:16 CST 2012 Josef Bacik <jbacik@fusionio.com> Btrfs: don't re-enter when allocating a chunk
If we start running low on metadata space we will try to allocate a chunk, which could then try to allocate a chunk to add the device entry. The thing is we allocate a chunk before we try really hard to make the allocation, so we should be able to find space for the device entry. Add a flag to the trans handle so we know we're currently allocating a chunk so we can just bail out if we try to allocate another chunk. Thanks,
Signed-off-by: Josef Bacik <jbacik@fusionio.com>
|