The return value of find_first_extent_bit is 1 or 0, no < 0.
And if found something, return 0; if nothing was found, return 1.
Fix the comment.
Signed-off-by: Wang Sheng-Hui
---
fs/btrfs/extent_io.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/fs/btrfs/extent_io.c b/
num_extent_pages returns the number of pages in the specific range, not
the index of the last page in the eb range.
btrfs_release_extent_buffer_page is called with start_idx set 0 in current
codes, so it's not a problem yet. But the logic is indeed wrong.
Fix it here.
Signed-off-by: Wang Sheng-H
No 'delete' arg is used for clear_state_bit.
Cleanup the comment.
Signed-off-by: Wang Sheng-Hui
---
fs/btrfs/extent_io.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/fs/btrfs/extent_io.c b/fs/btrfs/extent_io.c
index 7b679e2..5505356 100644
--- a/fs/btrfs/extent_io.c
In tree_insert, var *entry is used in the loop only, and is useless
out of the loop. Remove the useless assignment after the loop.
Signed-off-by: Wang Sheng-Hui
---
fs/btrfs/extent_io.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/fs/btrfs/extent_io.c b/fs/btrfs/exten
On 04/06/2012 09:24 AM, Liu Bo wrote:
> On 04/06/2012 04:09 AM, Mark Fasheh wrote:
>> Currently btrfs has a limitation on the maximum number of hard links an
>> inode can have. Specifically, links are stored in an array of ref
>> items:
>>
>> struct btrfs_inode_ref {
>> __le64 index;
>> _
On 04/06/2012 04:09 AM, Mark Fasheh wrote:
> Currently btrfs has a limitation on the maximum number of hard links an
> inode can have. Specifically, links are stored in an array of ref
> items:
>
> struct btrfs_inode_ref {
> __le64 index;
> __le16 name_len;
> /* name goes here */
(Note: I've changed my email address ;)
David Sterba wrote:
> On Mon, Mar 12, 2012 at 04:39:28PM +0800, Li Zefan wrote:
>> Currently it returns a set of bits that were cleared, but this return
>> value is not used at all.
>>
>> Moreover it doesn't seem to be useful, because we may clear the bits
Hi,
Firstly, thanks to developers for their work.
I'm a btrfs user and I wrote my bash completion file for "btrfs"
command. This way, I can use tab to complete command line in bash.
I'm sending you it. I hope you find it useful. In Debian-like distros
you should put it in /etc/bash_completion.d/
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/05/2012 04:09 PM, Mark Fasheh wrote:
> Currently btrfs has a limitation on the maximum number of hard
> links an inode can have. Specifically, links are stored in an array
> of ref items:
>
> struct btrfs_inode_ref { __le64 index; __le16 name_le
The iterate_irefs in backref.c is used to build path components from inode
refs. I had to add a 2nd iterate function callback to handle extended refs.
Both iterate callbacks eventually converge upon iref_to_path() which I was
able to keep as one function with some small code to abstract away
diffe
Teach tree-log.c about extended inode refs. In particular, we have to adjust
the behavior of inode ref replay as well as log tree recovery to account for
the existence of extended refs.
Signed-off-by: Mark Fasheh
---
fs/btrfs/tree-log.c | 320 +-
This patch adds basic support for extended inode refs. This includes support
for link and unlink of the refs, which basically gets us support for rename
as well.
Inode creation does not need changing - extended refs are only added after
the ref array is full.
Signed-off-by: Mark Fasheh
---
fs/b
Currently btrfs has a limitation on the maximum number of hard links an
inode can have. Specifically, links are stored in an array of ref
items:
struct btrfs_inode_ref {
__le64 index;
__le16 name_len;
/* name goes here */
} __attribute__ ((__packed__));
The ref arrays are
On Mon, Mar 12, 2012 at 04:39:28PM +0800, Li Zefan wrote:
> Currently it returns a set of bits that were cleared, but this return
> value is not used at all.
>
> Moreover it doesn't seem to be useful, because we may clear the bits
> of a few extent_states, but only the cleared bits of last one is
On Thu, Apr 05, 2012 at 12:23:01PM -0400, Bobby Powers wrote:
> On Wed, Apr 4, 2012 at 10:04 PM, Bobby Powers wrote:
> > spin_is_locked always returns 0 on non-SMP systems, which causes btrfs
> > to fail the mount. There is documentation pending as to why checking
>
> I guess I should be explici
On Wed, Apr 4, 2012 at 10:04 PM, Bobby Powers wrote:
> spin_is_locked always returns 0 on non-SMP systems, which causes btrfs
> to fail the mount. There is documentation pending as to why checking
I guess I should be explicit in stating that this is a regression, so
this patch or something else
16 matches
Mail list logo
