When inserting into the radix tree returns EEXIST, get the existing
entry without giving up the spinlock in between.
There was a race for both the zones trees and the extent tree.
Signed-off-by: Arne Jansen sensi...@gmx.net
---
fs/btrfs/reada.c | 36
1
Normally when there are 2 copies of a block, we add both to the
reada extent tree and prefetch only the one that is easier to reach.
This way we can better utilize multiple devices.
In case of DUP this makes no sense as both copies reside on the
same device.
Signed-off-by: Arne Jansen
Hi Martin,
I just sent 2 patches to the list. Could you please test if these
fix your problem with scrub?
Thanks,
Arne
On 02/24/12 16:51, Martin Steigerwald wrote:
Am Samstag, 21. Januar 2012 schrieb Martin Steigerwald:
Am Samstag, 21. Januar 2012 schrieb Martin Steigerwald:
I still have
Arne Jansen posted on Sat, 25 Feb 2012 09:09:47 +0100 as excerpted:
Normally when there are 2 copies of a block, we add both to the reada
extent tree and prefetch only the one that is easier to reach.
This way we can better utilize multiple devices.
In case of DUP this makes no sense as both
On 02/25/12 09:33, Duncan wrote:
Arne Jansen posted on Sat, 25 Feb 2012 09:09:47 +0100 as excerpted:
Normally when there are 2 copies of a block, we add both to the reada
extent tree and prefetch only the one that is easier to reach.
This way we can better utilize multiple devices.
In case of
Am Samstag, 25. Februar 2012 schrieb Arne Jansen:
Hi Martin,
I just sent 2 patches to the list. Could you please test if these
fix your problem with scrub?
I saved them and I try to. But no promises as to when. The machine is slow
at compiling kernels. And there are two annoying Pulseaudio
Arne Jansen posted on Sat, 25 Feb 2012 14:09:50 +0100 as excerpted:
On 02/25/12 09:33, Duncan wrote:
Arne Jansen posted on Sat, 25 Feb 2012 09:09:47 +0100 as excerpted:
Normally when there are 2 copies of a block, we add both to the reada
extent tree and prefetch only the one that is easier
I have a 5G /usr btrfs filesystem on a 3.0.0-12-generic kernel that is
returning ENOSPC when it's only 75% full:
FilesystemSize Used Avail Use% Mounted on
/dev/mapper/rootvol-mint_usr
5.0G 2.8G 967M 75% /usr
And yet I can't even unpack a linux-headers
btrfs is horrible for small filesystems (like a 5GB drive). df -h says
you have 967MB available, but btrfs (at least by default) allocates 1GB
at a time to data/metadata. This means that your 10MB file is too big
for the current allocation and requires a new data chunk, or another
1GB, which
On 2/25/2012 6:16 PM, Brian J. Murrell wrote:
Others might know of a way of changing the allocation size to less than
1GB, but otherwise I recommend switching to something more stable like
ext4/reiserfs/etc.
So btrfs is still not yet suitable to be a root/usr/var filesystem, even
in kernel
On 12-02-25 09:37 PM, Fahrzin Hemmati wrote:
Nope, still in heavy development, though you should upgrade to 3.2.
I recall being told I should upgrade to 2.6.36 (or was it .37 or .38) at
one time. Seems like one should always upgrade. :-/
Also, the devs mentioned in several places it's not
On 12-02-25 09:10 PM, Fahrzin Hemmati wrote:
btrfs is horrible for small filesystems (like a 5GB drive). df -h says
you have 967MB available, but btrfs (at least by default) allocates 1GB
at a time to data/metadata. This means that your 10MB file is too big
for the current allocation and
On 2/25/2012 9:45 PM, Brian J. Murrell wrote:
On 12-02-25 09:10 PM, Fahrzin Hemmati wrote:
btrfs is horrible for small filesystems (like a 5GB drive). df -h says
you have 967MB available, but btrfs (at least by default) allocates 1GB
at a time to data/metadata. This means that your 10MB file is
On Sun, Feb 26, 2012 at 1:14 AM, Brian J. Murrell br...@interlinx.bc.ca wrote:
# btrfs fi resize 5G /usr; df -h /usr
Resize '/usr' of '5G'
What would be interesting is getting an eye on btrfs fi df of your
filesystem to see what part is getting full, or maybe just do a
balance.
I have been
14 matches
Mail list logo
