[PATCH 0/3] btrfs: extended inode refs

2012-08-08 Thread Mark Fasheh
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

[PATCH 0/3] btrfs: extended inode refs

2012-05-21 Thread Mark Fasheh
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

Re: [PATCH 0/3] btrfs: extended inode refs

2012-04-12 Thread Mark Fasheh
On Thu, Apr 12, 2012 at 12:11:13PM -0400, Chris Mason wrote: > On Wed, Apr 11, 2012 at 03:11:46PM +0200, Jan Schmidt wrote: > > Hi Jeff, > > > > > >> An alternative solution to dealing with collisions could be to > > >> emulate the dir-item insertion code - specifically something like > > >> inser

Re: [PATCH 0/3] btrfs: extended inode refs

2012-04-12 Thread Chris Mason
On Wed, Apr 11, 2012 at 03:11:46PM +0200, Jan Schmidt wrote: > Hi Jeff, > > > >> An alternative solution to dealing with collisions could be to > >> emulate the dir-item insertion code - specifically something like > >> insert_with_overflow() which will stuff multiple items under one > >> key. I t

Re: [PATCH 0/3] btrfs: extended inode refs

2012-04-11 Thread Jan Schmidt
On 11.04.2012 15:11, Jan Schmidt wrote: > Hi Jeff, > > On 05.04.2012 23:13, Jeff Mahoney wrote: >>> As a result, we must use a different addressing scheme. Extended >>> ref keys look like: >> >>> (inode objectid, BTRFS_INODE_EXTREF_KEY, hash) >> >>> Where hash is defined as a function of the paren

Re: [PATCH 0/3] btrfs: extended inode refs

2012-04-11 Thread Jan Schmidt
Hi Jeff, On 05.04.2012 23:13, Jeff Mahoney wrote: >> As a result, we must use a different addressing scheme. Extended >> ref keys look like: > >> (inode objectid, BTRFS_INODE_EXTREF_KEY, hash) > >> Where hash is defined as a function of the parent objectid and link >> name. > > I think this is

Re: [PATCH 0/3] btrfs: extended inode refs

2012-04-05 Thread Liu Bo
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; >> _

Re: [PATCH 0/3] btrfs: extended inode refs

2012-04-05 Thread Liu Bo
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 */

Re: [PATCH 0/3] btrfs: extended inode refs

2012-04-05 Thread Jeff Mahoney
-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

[PATCH 0/3] btrfs: extended inode refs

2012-04-05 Thread Mark Fasheh
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