It is necessary to unlock mutex_lock before it return an error when
btrfs_alloc_path() fails.
Signed-off-by: Tsutomu Itoh t-i...@jp.fujitsu.com
---
fs/btrfs/tree-log.c |7 +--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/fs/btrfs/tree-log.c b/fs/btrfs/tree-log.c
index
From: Itaru Kitayama kitay...@cl.bb4u.ne.jp
the space cache use extent_readpages() to read free space information,
so we can not use GFP_KERNEL flag to allocate memory, or it may lead
to deadlock.
Signed-off-by: Itaru Kitayama kitay...@cl.bb4u.ne.jp
Signed-off-by: Miao Xie mi...@cn.fujitsu.com
Since we have implemented the delayed update of the inode, we can also
delayed to insert the initial inode, then we can merge the inode update
and the initial inode insertions to one insertion.
Signed-off-by: Miao Xie mi...@cn.fujitsu.com
---
fs/btrfs/delayed-inode.c | 18 +--
On 2011.04.22 at 00:50 -0400, Christoph Hellwig wrote:
[Eric: please don't drop the Cc list, thanks!]
On Thu, Apr 21, 2011 at 09:22:55PM -0400, Josef Bacik wrote:
since all files have a virtual hole at the end, but leaves the position
unchanged). ??I'd have to write a test program on
[resending, did not reach the list yesterday]
Hi,
sending out first bunch of function interface cleanups, removing unused
parameters in the easily reviewable cases, plus some compiler warning fixes. No
functional changes.
There is a measurable effect on code text size
(master is Linux
reported by gcc -Wshadow:
page_index, page_offset, new_inode, dev_name
Signed-off-by: David Sterba dste...@suse.cz
---
fs/btrfs/compression.c | 42 +-
fs/btrfs/compression.h |2 +-
fs/btrfs/ctree.h |2 +-
fs/btrfs/disk-io.c |2 +-
use IS_ERR_OR_NULL when possible, done by this coccinelle script:
@ match @
identifier id;
@@
(
- BUG_ON(IS_ERR(id) || !id);
+ BUG_ON(IS_ERR_OR_NULL(id));
|
- IS_ERR(id) || !id
+ IS_ERR_OR_NULL(id)
|
- !id || IS_ERR(id)
+ IS_ERR_OR_NULL(id)
)
Signed-off-by: David Sterba dste...@suse.cz
---
Signed-off-by: David Sterba dste...@suse.cz
---
fs/btrfs/extent-tree.c |6 --
1 files changed, 0 insertions(+), 6 deletions(-)
diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
index 31f33ba..c97ceab 100644
--- a/fs/btrfs/extent-tree.c
+++ b/fs/btrfs/extent-tree.c
@@ -756,8
The superblock's -s_fs_info is properly set in btrfs_fill_super, after
a call to open_ctree, which derefereces it before check. Although
tree_root is set via btrfs_set_super, let's be defensive and leave the
check in place.
Signed-off-by: David Sterba dste...@suse.cz
---
fs/btrfs/disk-io.c |
Signed-off-by: David Sterba dste...@suse.cz
---
fs/btrfs/ctree.c|1 -
fs/btrfs/free-space-cache.c |3 ---
2 files changed, 0 insertions(+), 4 deletions(-)
diff --git a/fs/btrfs/ctree.c b/fs/btrfs/ctree.c
index 84d7ca1..c60197b 100644
--- a/fs/btrfs/ctree.c
+++
pass GFP_NOFS directly to kmem_cache_alloc
Signed-off-by: David Sterba dste...@suse.cz
---
fs/btrfs/disk-io.c |6 +++---
fs/btrfs/extent_io.c |7 +++
fs/btrfs/extent_io.h |3 +--
3 files changed, 7 insertions(+), 9 deletions(-)
diff --git a/fs/btrfs/disk-io.c
pass GFP_NOFS directly to kmem_cache_alloc
Signed-off-by: David Sterba dste...@suse.cz
---
fs/btrfs/disk-io.c |4 ++--
fs/btrfs/extent_io.c |3 +--
fs/btrfs/extent_io.h |3 +--
3 files changed, 4 insertions(+), 6 deletions(-)
diff --git a/fs/btrfs/disk-io.c b/fs/btrfs/disk-io.c
pass GFP_NOFS directly to kmem_cache_alloc
Signed-off-by: David Sterba dste...@suse.cz
---
fs/btrfs/disk-io.c |2 +-
fs/btrfs/extent-tree.c |2 +-
fs/btrfs/extent_map.c |5 ++---
fs/btrfs/extent_map.h |2 +-
fs/btrfs/file.c|4 ++--
fs/btrfs/inode.c | 12
parameter tree root it's not used since commit
5f39d397dfbe140a14edecd4e73c34ce23c4f9ee (Btrfs: Create extent_buffer
interface for large blocksizes)
Signed-off-by: David Sterba dste...@suse.cz
---
fs/btrfs/ctree.c| 28 ++--
fs/btrfs/ctree.h|2 +-
Signed-off-by: David Sterba dste...@suse.cz
---
fs/btrfs/ctree.c|4 ++--
fs/btrfs/extent-tree.c |6 +++---
fs/btrfs/free-space-cache.c |4 ++--
3 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/fs/btrfs/ctree.c b/fs/btrfs/ctree.c
index c60197b..a36c87db
On 04/22/2011 05:28 AM, Markus Trippelsdorf wrote:
On 2011.04.22 at 00:50 -0400, Christoph Hellwig wrote:
[Eric: please don't drop the Cc list, thanks!]
That's the fault of gmane. My apologies for not being subscribed in the
first place, and for gmane's refusal to cc all. Now that I'm on the
On Fri, Apr 22, 2011 at 10:23:14AM +0900, Tsutomu Itoh wrote:
But, reading code again, I noticed nobody use relocate_one_extent() now. ;-)
However, because there is a possibility to be going to be used in the future,
I'll add the check of 'new_extents' for the readability.
vim hilight confused
Hi,
On Fri, Apr 22, 2011 at 06:05:40PM +0900, Tsutomu Itoh wrote:
It is necessary to unlock mutex_lock before it return an error when
btrfs_alloc_path() fails.
good catch! however I suggest to move the mutex_lock after the
allocation and check, it'll be semantically equivalent to your change,
On 04/22/2011 05:28 AM, Markus Trippelsdorf wrote:
I would be surprised if the bug is around for such a long time, but
otherwise I concur.
It's a bug. Let me quote what Jeff Bonwick wrote on his blog:
»I'm not sure where you got the impression that either SEEK_HOLE or
SEEK_DATA doesn't
On Thursday 21 April, 2011 11:47:25 Calvin Walton wrote:
You have nothing to worry about. You can delete any snapshot on btrfs
without losing data from any other snapshot. Each snapshot is completely
independent.
This works because data which is shared between multiple snapshots is
On Fri, Apr 22, 2011 at 10:03 PM, cac...@quantum-sci.com wrote:
Would it be good practice to say, once a year, do a completely new fresh
snapshot?
There's no such thing as new fresh snapshot.
You can create a new, empty subvolume.
Or you can create snapshot of existing root/subvolume, which
Hallo, Calvin,
Du meintest am 21.04.11:
I have set up a backup server in the garage which does rsync backups
of all my servers weekly, and snapshots those backups.
[...]
You have nothing to worry about. You can delete any snapshot on btrfs
without losing data from any other snapshot. Each
On 04/22/2011 04:50 AM, Eric Blake wrote:
That blog also mentioned the useful idea of adding FIND_HOLE and
FIND_DATA, not implemented in Solaris, but which could easily be
provided as additional lseek constants in Linux to locate the start of
the next chunk without repositioning and which could
On 04/22/2011 10:28 AM, Sunil Mushran wrote:
On 04/22/2011 04:50 AM, Eric Blake wrote:
That blog also mentioned the useful idea of adding FIND_HOLE and
FIND_DATA, not implemented in Solaris, but which could easily be
provided as additional lseek constants in Linux to locate the start of
the
On 04/22/2011 09:40 AM, Eric Blake wrote:
On 04/22/2011 10:28 AM, Sunil Mushran wrote:
while(1) {
read(block);
if (block_all_zeroes)
lseek(SEEK_DATA);
}
What's wrong with the above? If this is the case, even SEEK_HOLE
is not needed but should be added as it is already in
On 04/22/2011 10:57 AM, Sunil Mushran wrote:
On 04/22/2011 09:40 AM, Eric Blake wrote:
On 04/22/2011 10:28 AM, Sunil Mushran wrote:
while(1) {
read(block);
if (block_all_zeroes)
lseek(SEEK_DATA);
}
What's wrong with the above? If this is the case, even SEEK_HOLE
is not
On 04/22/2011 10:03 AM, Eric Blake wrote:
cp can read whatever blocksize it chooses. If that block contains
zero, it would signal cp that maybe it should SEEK_DATA and skip
reading all those blocks. That's all. We are not trying to achieve
perfection. We are just trying to reduce cpu waste.
If
On 2011-04-22, at 11:08 AM, Sunil Mushran sunil.mush...@oracle.com wrote:
On 04/22/2011 10:03 AM, Eric Blake wrote:
cp can read whatever blocksize it chooses. If that block contains
zero, it would signal cp that maybe it should SEEK_DATA and skip
reading all those blocks. That's all. We are
On Fri, 08 Apr 2011 16:44:37 +0800
liubo liubo2...@cn.fujitsu.com wrote:
When a btrfs disk is created by mixed data metadata option, it will have no
pure data or pure metadata space info.
In btrfs's for-linus branch, commit 78b1ea13838039cd88afdd62519b40b344d6c920
(Btrfs: fix OOPS of
Hi,
Josef Bacik wrote:
This just gets us ready to support the SEEK_HOLE and SEEK_DATA flags. Turns
out
using fiemap in things like cp cause more problems than it solves, so lets try
and give userspace an interface that doesn't suck. So we have
That's easy to believe, but could you
On 04/22/2011 01:10 PM, Jonathan Nieder wrote:
Hi,
Josef Bacik wrote:
This just gets us ready to support the SEEK_HOLE and SEEK_DATA flags. Turns out
using fiemap in things like cp cause more problems than it solves, so lets try
and give userspace an interface that doesn't suck. So we have
On 04/22/2011 11:06 AM, Andreas Dilger wrote:
Sure, there are lots of wasted syscalls, but in this case the cost of doing
extra SEEK_DATA and SEEK_HOLE operations may be fairly costly. This involves
scanning the whole disk layout, possibly over a network, which might need tens
or hundreds of
32 matches
Mail list logo
