On Tuesday 25 of January 2011 07:45:02 Magicloud Magiclouds wrote:
Hi,
I am using 2.6.36.3 kernel with btrfs, 512MB memory and a very slow
disk, no special options for mounting btrfs except noatime. Now I
found it very slow. When I rm a 5GB movie, it took 20 secs.
try mounting with
Hallo, Chris,
Du meintest am 25.01.11:
Regard the difference between df and btrfs filesystem df.
I suspect this is fixed in 2.6.38 with the following commit.
BE WARNED: there are some fairly hairy changes to the pathname
lookup code to replace the BKL with RCU (not specific to btrfs)
and
On Tuesday, January 25, 2011 15:28:11 Magicloud Magiclouds wrote:
So you were saying that, even an unlink operation, the system walks
through all file data blocks? I thought unlink wouldn't have to write
too much data.
No, but the amount of data to be changed if the number of extents is small
On Tue, Jan 25, 2011 at 09:51:01AM +0100, Daniel Poelzleithner wrote:
Hi,
Since update to 2.6.37 I can't build openwrt on my btrfs buildroot anymore.
I'm not sure if this is related to the other flush-btrfs-1 thread.
plenty of diskspace is free:
/dev/mapper/cruor-build
On 01/22/2011 02:55 PM, Hubert Kario wrote:
It looks like ZFS, Btrfs, and LVM should work in similar manners, but
the overloaded terminology (pool, volume, sub-volume, filesystem are
different in all three) and new terminology that's only in Btrfs is
confusing.
With btrfs you need to have *a*
On Tuesday, January 25, 2011 18:29:35 Kaspar Schleiser wrote:
On 01/22/2011 02:55 PM, Hubert Kario wrote:
It looks like ZFS, Btrfs, and LVM should work in similar manners, but
the overloaded terminology (pool, volume, sub-volume, filesystem are
different in all three) and new terminology
Sorry, but these were bugging me. Just cleanup some of the formatting in
file.c.
Signed-off-by: Josef Bacik jo...@redhat.com
---
fs/btrfs/file.c | 16
1 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/fs/btrfs/file.c b/fs/btrfs/file.c
index c800d58..a754865
On Tuesday, January 25, 2011 18:59:39 Freddie Cash wrote:
On Tue, Jan 25, 2011 at 9:43 AM, Hubert Kario h...@qbs.com.pl wrote:
Besides, I don't see *why* this should be done...
And as far as I know ZFS doesn't support different reduncancy levels for
different files residing in the same
Hello all,
Last Friday, the /var and /home partition on one of my appliances became
full. This should normally not be much of a problem, except that after
the incident, I had been unable to mount the partition back again.
The appliance runs 2.6.32 as provided by Debian during the last two
Our aio_write function is huge and kind of hard to follow at times. So this
patch fixes this by breaking out the buffered and direct write paths out into
seperate functions so it's a little clearer what's going on. I've also fixed
some wrong typing that we had and added the ability to handle
Really we don't need to memset the pages array at all, since we know how many
pages we're going to use in the array and pass that around. So don't memset,
just trust we're not idiots and we pass num_pages around properly.
Signed-off-by: Josef Bacik jo...@redhat.com
---
fs/btrfs/file.c | 10
Instead of doing a BUG_ON(1) in prepare_pages if grab_cache_page() fails, just
loop through the pages we've already grabbed and unlock and release them, then
return -ENOMEM like we should. Thanks,
Signed-off-by: Josef Bacik jo...@redhat.com
---
fs/btrfs/file.c |8 ++--
1 files changed,
There is a missing break in switch, fix it.
Signed-off-by: Liu Bo liubo2...@cn.fujitsu.com
---
fs/btrfs/print-tree.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/fs/btrfs/print-tree.c b/fs/btrfs/print-tree.c
index 0d126be..fb2605d 100644
--- a/fs/btrfs/print-tree.c
13 matches
Mail list logo
