Le mardi 25 janvier 2011 à 23:38 -0500, Shawn Stricker a écrit :
> Not sure where you pulled your source from but a fresh checkout of either
> master or next of
> git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-progs-unstable.git does
> not compile properly.
> They both fail with
>
> cc1:
There is a missing break in switch, fix it.
Signed-off-by: Liu Bo
---
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
+++ b/fs/btrfs/print-tree.
btrfs_submit_compressed_read() is lack of memory allocation checks and
corresponding error route.
After this fix, if it comes to "no memory" case, errno will be returned
to userland step by step, and tell users this operation cannot go on.
Signed-off-by: Liu Bo
---
fs/btrfs/compression.c | 2
To make btrfs more stable, add several missing necessary memory allocation
checks, and when no memory, return proper errno.
We've checked that some of those -ENOMEM errors will be returned to
userspace, and some will be catched by BUG_ON() in the upper callers,
and none will be ignored silently.
Not sure where you pulled your source from but a fresh checkout of either
master or next of
git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-progs-unstable.git does not
compile properly.
They both fail with
cc1: warnings being treated as errors
disk-io.c: In function ‘btrfs_read_dev_super’:
- Create an initial ino extent in the fs tree.
- Add debug code to btrfs-debug-tree command.
Singed-off-by: Li Zefan
---
ctree.h |2 ++
mkfs.c | 16
print-tree.c | 23 ++-
3 files changed, 40 insertions(+), 1 deletions(-)
diff --git a/ctre
(WARNING: this patch is not completed or well-tested)
We used to allocate inode number by searching through inode items, but
it made the allocation slower and slower as more and more files created.
The current code just records the highest objectid in the btree without
reusing old inode numbers,
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
---
fs/btrfs/file.c |8 ++--
1 files changed, 6 insertions(+),
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
---
fs/btrfs/file.c | 10 +-
1 files
We track delayed allocation per inodes via 2 counters, one is
outstanding_extents and reserved_extents. Outstanding_extents is already an
atomic_t, but reserved_extents is not and is protected by a spinlock. So
convert this to an atomic_t and instead of using a spinlock, use atomic_cmpxchg
when r
On 01/25/2011 04:30 PM, Josef Bacik wrote:
> How about sysrq+w when it's hanging.
Shows nothing.
> Also could you give the exact steps to
> reproduce? I went to the openwrt site to try and build, but it seems like
> theres alot of moving parts. If you can just tell me what to download and
>
On Mon, Jan 24, 2011 at 12:21 PM, Hubert Kario wrote:
> On Monday, January 24, 2011 19:11:07 Mitch Harder wrote:
>> Defragmentation is not working when a directory is supplied as the
>> argument. When a file name is supplied as the argument,
>> defragmentation works well.
>>
>> This can be demons
We already memset the pages array in __btrfs_buffered_write, there's no need to
do it again in prepare_pages.
Signed-off-by: Josef Bacik
---
fs/btrfs/file.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/fs/btrfs/file.c b/fs/btrfs/file.c
index c0f312a..fd89c5c 100644
--
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 gett
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
months.
On Tuesday, January 25, 2011 18:59:39 Freddie Cash wrote:
> On Tue, Jan 25, 2011 at 9:43 AM, Hubert Kario 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 director
On Tue, Jan 25, 2011 at 9:43 AM, Hubert Kario 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 directory. You can have
> ~/1billion$-project.tar.gz with triple redundancy a
Sorry, but these were bugging me. Just cleanup some of the formatting in
file.c.
Signed-off-by: Josef Bacik
---
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 100644
--- a/fs/btrfs/
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 termi
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* f
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 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 smal
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 btrf
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.
On Tue, Jan 25, 2011 at 6:30 PM, Hubert Kario wrote:
> On Tuesday 25 of January 2011 07:45:02 Magicloud Magiclouds wrote:
>> Hi,
>> I am using
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 nodat
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
97G 68G 27G 73% /opt/build
It always hangs when openwrt builds the
26 matches
Mail list logo
