On 05/21/2012 06:05 PM, Alex Lyakas wrote:
> Hi Liu,
> thanks for the clarifications.
>
> I did not understand the dd example of yours, though.
>
>> So for the following situation:
>>> item 23 key (266 EXTENT_DATA 4096) itemoff 2269 itemsize 53
>>> extent data disk byte 0 nr
From: Mark Fasheh
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/backref.c | 68 +++
fs/btrfs/backref.h
From: Mark Fasheh
The iterate_irefs in backref.c is used to build path components from inode
refs. This patch adds code to iterate extended refs as well.
I had modify the callback function signature to abstract out some of the
differences between ref structures. iref_to_path() also needed simila
From: Mark Fasheh
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: Ma
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 Fri, 18 May 2012 13:57:19 +0200, David Sterba wrote:
> On Wed, May 16, 2012 at 06:50:47PM +0200, Stefan Behrens wrote:
>> --- a/fs/btrfs/ctree.h
>> +++ b/fs/btrfs/ctree.h
>> @@ -823,6 +823,26 @@ struct btrfs_csum_item {
>> u8 csum;
>> } __attribute__ ((__packed__));
>>
>> +struct btrfs_d
Hi Alex,
On Fri, May 18, 2012 at 13:21 (+0200), Alex Lyakas wrote:
> Some general questions on the ctree code.
>
> # I saw that slot==0 is special. My understanding is that btrfs
> maintains the property that the parent of each node/leaf has a key
> pointing to that node/leaf, which must be equal
On 21.05.2012 07:34, Miao Xie wrote:
> On Fri, 18 May 2012 14:52:07 +0200, David Sterba wrote:
>> On Thu, May 17, 2012 at 07:58:21PM +0800, Miao Xie wrote:
>>> --- a/fs/btrfs/super.c
>>> +++ b/fs/btrfs/super.c
>>> @@ -1151,6 +1151,8 @@ static int btrfs_remount(struct super_block *sb, int
>>> *flag
On Mon, 21 May 2012 13:34:05 +0800, Miao Xie wrote:
> On Fri, 18 May 2012 14:52:07 +0200, David Sterba wrote:
>> On Thu, May 17, 2012 at 07:58:21PM +0800, Miao Xie wrote:
>>> --- a/fs/btrfs/super.c
>>> +++ b/fs/btrfs/super.c
>>> @@ -1151,6 +1151,8 @@ static int btrfs_remount(struct super_block *sb,
Hi Liu,
thanks for the clarifications.
I did not understand the dd example of yours, though.
> So for the following situation:
>> item 23 key (266 EXTENT_DATA 4096) itemoff 2269 itemsize 53
>> extent data disk byte 0 nr 0
>> extent data offset 0 nr 4096 ram 8192
On 05/21/2012 04:20 PM, Alex Lyakas wrote:
> Hi Liu,
> do you think that this should not happen? I see this all the time, and
> I am not doing any stress tests. Just creating a file and writing some
> data at different offsets, to create "holes" in the file offset space.
> btrfsck does not produce
Hi Liu,
do you think that this should not happen? I see this all the time, and
I am not doing any stress tests. Just creating a file and writing some
data at different offsets, to create "holes" in the file offset space.
btrfsck does not produce any errors.
I am using kernel 3.3.6 and btrfs-progrs
12 matches
Mail list logo
