On Sun, Feb 26, 2012 at 1:14 AM, Brian J. Murrell 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 running 3.0.0 for qu
On 12-02-26 12:45 AM, Brian J. Murrell wrote:
>
> So I guess I need a 50G btrfs filesystem for 2.8G worth of data?
Interestingly enough, I was able to resize the filesystem back down to
5G after all of that:
# btrfs fi resize 5G /usr; df -h /usr
Resize '/usr' of '5G'
FilesystemSize
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 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 re
On 2/25/2012 7:57 PM, Brian J. Murrell wrote:
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. :-/
It's a ne
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 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 3.0.0
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,
So does dd. It manages to write that 967MB before getting an ENOSPC.
> but btrfs (at least by default) allocates 1GB
> at a time to data/metadata.
Bl
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 yo
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 package
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
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 Pulseaud
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 D
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 bo
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 th
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
---
fs/btr
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
---
fs/btrfs/reada.c | 36
1 files changed, 16 ins
17 matches
Mail list logo
