* [PATCH] Btrfs: use i_version instead of our own sequence @ 2012-04-09 15:53 Josef Bacik 2012-04-12 13:22 ` Kasatkin, Dmitry 0 siblings, 1 reply; 10+ messages in thread From: Josef Bacik @ 2012-04-09 15:53 UTC (permalink / raw) To: linux-btrfs We've been keeping around the inode sequence number in hopes that somebody would use it, but nobody uses it and people actually use i_version which serves the same purpose, so use i_version where we used the incore inode's sequence number and that way the sequence is updated properly across the board, and not just in file write. Thanks, Signed-off-by: Josef Bacik <josef@redhat.com> --- fs/btrfs/btrfs_inode.h | 3 --- fs/btrfs/delayed-inode.c | 4 ++-- fs/btrfs/file.c | 1 - fs/btrfs/inode.c | 5 ++--- fs/btrfs/super.c | 2 +- 5 files changed, 5 insertions(+), 10 deletions(-) diff --git a/fs/btrfs/btrfs_inode.h b/fs/btrfs/btrfs_inode.h index 9b9b15f..3771b85 100644 --- a/fs/btrfs/btrfs_inode.h +++ b/fs/btrfs/btrfs_inode.h @@ -83,9 +83,6 @@ struct btrfs_inode { */ u64 generation; - /* sequence number for NFS changes */ - u64 sequence; - /* * transid of the trans_handle that last modified this inode */ diff --git a/fs/btrfs/delayed-inode.c b/fs/btrfs/delayed-inode.c index 03e3748..bcd40c7 100644 --- a/fs/btrfs/delayed-inode.c +++ b/fs/btrfs/delayed-inode.c @@ -1706,7 +1706,7 @@ static void fill_stack_inode_item(struct btrfs_trans_handle *trans, btrfs_set_stack_inode_nbytes(inode_item, inode_get_bytes(inode)); btrfs_set_stack_inode_generation(inode_item, BTRFS_I(inode)->generation); - btrfs_set_stack_inode_sequence(inode_item, BTRFS_I(inode)->sequence); + btrfs_set_stack_inode_sequence(inode_item, inode->i_version); btrfs_set_stack_inode_transid(inode_item, trans->transid); btrfs_set_stack_inode_rdev(inode_item, inode->i_rdev); btrfs_set_stack_inode_flags(inode_item, BTRFS_I(inode)->flags); @@ -1754,7 +1754,7 @@ int btrfs_fill_inode(struct inode *inode, u32 *rdev) set_nlink(inode, btrfs_stack_inode_nlink(inode_item)); inode_set_bytes(inode, btrfs_stack_inode_nbytes(inode_item)); BTRFS_I(inode)->generation = btrfs_stack_inode_generation(inode_item); - BTRFS_I(inode)->sequence = btrfs_stack_inode_sequence(inode_item); + inode->i_version = btrfs_stack_inode_sequence(inode_item); inode->i_rdev = 0; *rdev = btrfs_stack_inode_rdev(inode_item); BTRFS_I(inode)->flags = btrfs_stack_inode_flags(inode_item); diff --git a/fs/btrfs/file.c b/fs/btrfs/file.c index 431b565..f0da02b 100644 --- a/fs/btrfs/file.c +++ b/fs/btrfs/file.c @@ -1404,7 +1404,6 @@ static ssize_t btrfs_file_aio_write(struct kiocb *iocb, mutex_unlock(&inode->i_mutex); goto out; } - BTRFS_I(inode)->sequence++; start_pos = round_down(pos, root->sectorsize); if (start_pos > i_size_read(inode)) { diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c index 7a084fb..7d3dd2f 100644 --- a/fs/btrfs/inode.c +++ b/fs/btrfs/inode.c @@ -2510,7 +2510,7 @@ static void btrfs_read_locked_inode(struct inode *inode) inode_set_bytes(inode, btrfs_inode_nbytes(leaf, inode_item)); BTRFS_I(inode)->generation = btrfs_inode_generation(leaf, inode_item); - BTRFS_I(inode)->sequence = btrfs_inode_sequence(leaf, inode_item); + inode->i_version = btrfs_inode_sequence(leaf, inode_item); inode->i_generation = BTRFS_I(inode)->generation; inode->i_rdev = 0; rdev = btrfs_inode_rdev(leaf, inode_item); @@ -2594,7 +2594,7 @@ static void fill_inode_item(struct btrfs_trans_handle *trans, btrfs_set_inode_nbytes(leaf, item, inode_get_bytes(inode)); btrfs_set_inode_generation(leaf, item, BTRFS_I(inode)->generation); - btrfs_set_inode_sequence(leaf, item, BTRFS_I(inode)->sequence); + btrfs_set_inode_sequence(leaf, item, inode->i_version); btrfs_set_inode_transid(leaf, item, trans->transid); btrfs_set_inode_rdev(leaf, item, inode->i_rdev); btrfs_set_inode_flags(leaf, item, BTRFS_I(inode)->flags); @@ -6884,7 +6884,6 @@ struct inode *btrfs_alloc_inode(struct super_block *sb) ei->root = NULL; ei->space_info = NULL; ei->generation = 0; - ei->sequence = 0; ei->last_trans = 0; ei->last_sub_trans = 0; ei->logged_trans = 0; diff --git a/fs/btrfs/super.c b/fs/btrfs/super.c index 54e7ee9..ee1bb31 100644 --- a/fs/btrfs/super.c +++ b/fs/btrfs/super.c @@ -770,7 +770,7 @@ static int btrfs_fill_super(struct super_block *sb, #ifdef CONFIG_BTRFS_FS_POSIX_ACL sb->s_flags |= MS_POSIXACL; #endif - + sb->s_flags |= MS_I_VERSION; err = open_ctree(sb, fs_devices, (char *)data); if (err) { printk("btrfs: open_ctree failed\n"); -- 1.7.5.2 ^ permalink raw reply related [flat|nested] 10+ messages in thread
* Re: [PATCH] Btrfs: use i_version instead of our own sequence 2012-04-09 15:53 [PATCH] Btrfs: use i_version instead of our own sequence Josef Bacik @ 2012-04-12 13:22 ` Kasatkin, Dmitry 2012-04-12 13:31 ` Josef Bacik 0 siblings, 1 reply; 10+ messages in thread From: Kasatkin, Dmitry @ 2012-04-12 13:22 UTC (permalink / raw) To: Josef Bacik; +Cc: linux-btrfs On Mon, Apr 9, 2012 at 6:53 PM, Josef Bacik <josef@redhat.com> wrote: > We've been keeping around the inode sequence number in hopes that som= ebody > would use it, but nobody uses it and people actually use i_version wh= ich > serves the same purpose, so use i_version where we used the incore in= ode's > sequence number and that way the sequence is updated properly across = the > board, and not just in file write. =C2=A0Thanks, > > Signed-off-by: Josef Bacik <josef@redhat.com> > --- > =C2=A0fs/btrfs/btrfs_inode.h =C2=A0 | =C2=A0 =C2=A03 --- > =C2=A0fs/btrfs/delayed-inode.c | =C2=A0 =C2=A04 ++-- > =C2=A0fs/btrfs/file.c =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0= 1 - > =C2=A0fs/btrfs/inode.c =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A05 += +--- > =C2=A0fs/btrfs/super.c =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A02 += - > =C2=A05 files changed, 5 insertions(+), 10 deletions(-) > > diff --git a/fs/btrfs/btrfs_inode.h b/fs/btrfs/btrfs_inode.h > index 9b9b15f..3771b85 100644 > --- a/fs/btrfs/btrfs_inode.h > +++ b/fs/btrfs/btrfs_inode.h > @@ -83,9 +83,6 @@ struct btrfs_inode { > =C2=A0 =C2=A0 =C2=A0 =C2=A0 */ > =C2=A0 =C2=A0 =C2=A0 =C2=A0u64 generation; > > - =C2=A0 =C2=A0 =C2=A0 /* sequence number for NFS changes */ > - =C2=A0 =C2=A0 =C2=A0 u64 sequence; > - > =C2=A0 =C2=A0 =C2=A0 =C2=A0/* > =C2=A0 =C2=A0 =C2=A0 =C2=A0 * transid of the trans_handle that last m= odified this inode > =C2=A0 =C2=A0 =C2=A0 =C2=A0 */ > diff --git a/fs/btrfs/delayed-inode.c b/fs/btrfs/delayed-inode.c > index 03e3748..bcd40c7 100644 > --- a/fs/btrfs/delayed-inode.c > +++ b/fs/btrfs/delayed-inode.c > @@ -1706,7 +1706,7 @@ static void fill_stack_inode_item(struct btrfs_= trans_handle *trans, > =C2=A0 =C2=A0 =C2=A0 =C2=A0btrfs_set_stack_inode_nbytes(inode_item, i= node_get_bytes(inode)); > =C2=A0 =C2=A0 =C2=A0 =C2=A0btrfs_set_stack_inode_generation(inode_ite= m, > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = BTRFS_I(inode)->generation); > - =C2=A0 =C2=A0 =C2=A0 btrfs_set_stack_inode_sequence(inode_item, BTR= =46S_I(inode)->sequence); > + =C2=A0 =C2=A0 =C2=A0 btrfs_set_stack_inode_sequence(inode_item, ino= de->i_version); > =C2=A0 =C2=A0 =C2=A0 =C2=A0btrfs_set_stack_inode_transid(inode_item, = trans->transid); > =C2=A0 =C2=A0 =C2=A0 =C2=A0btrfs_set_stack_inode_rdev(inode_item, ino= de->i_rdev); > =C2=A0 =C2=A0 =C2=A0 =C2=A0btrfs_set_stack_inode_flags(inode_item, BT= RFS_I(inode)->flags); > @@ -1754,7 +1754,7 @@ int btrfs_fill_inode(struct inode *inode, u32 *= rdev) > =C2=A0 =C2=A0 =C2=A0 =C2=A0set_nlink(inode, btrfs_stack_inode_nlink(i= node_item)); > =C2=A0 =C2=A0 =C2=A0 =C2=A0inode_set_bytes(inode, btrfs_stack_inode_n= bytes(inode_item)); > =C2=A0 =C2=A0 =C2=A0 =C2=A0BTRFS_I(inode)->generation =3D btrfs_stack= _inode_generation(inode_item); > - =C2=A0 =C2=A0 =C2=A0 BTRFS_I(inode)->sequence =3D btrfs_stack_inode= _sequence(inode_item); > + =C2=A0 =C2=A0 =C2=A0 inode->i_version =3D btrfs_stack_inode_sequenc= e(inode_item); > =C2=A0 =C2=A0 =C2=A0 =C2=A0inode->i_rdev =3D 0; > =C2=A0 =C2=A0 =C2=A0 =C2=A0*rdev =3D btrfs_stack_inode_rdev(inode_ite= m); > =C2=A0 =C2=A0 =C2=A0 =C2=A0BTRFS_I(inode)->flags =3D btrfs_stack_inod= e_flags(inode_item); > diff --git a/fs/btrfs/file.c b/fs/btrfs/file.c > index 431b565..f0da02b 100644 > --- a/fs/btrfs/file.c > +++ b/fs/btrfs/file.c > @@ -1404,7 +1404,6 @@ static ssize_t btrfs_file_aio_write(struct kioc= b *iocb, > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0mutex_unlock(&= inode->i_mutex); > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0goto out; > =C2=A0 =C2=A0 =C2=A0 =C2=A0} > - =C2=A0 =C2=A0 =C2=A0 BTRFS_I(inode)->sequence++; > > =C2=A0 =C2=A0 =C2=A0 =C2=A0start_pos =3D round_down(pos, root->sector= size); > =C2=A0 =C2=A0 =C2=A0 =C2=A0if (start_pos > i_size_read(inode)) { > diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c > index 7a084fb..7d3dd2f 100644 > --- a/fs/btrfs/inode.c > +++ b/fs/btrfs/inode.c > @@ -2510,7 +2510,7 @@ static void btrfs_read_locked_inode(struct inod= e *inode) > > =C2=A0 =C2=A0 =C2=A0 =C2=A0inode_set_bytes(inode, btrfs_inode_nbytes(= leaf, inode_item)); > =C2=A0 =C2=A0 =C2=A0 =C2=A0BTRFS_I(inode)->generation =3D btrfs_inode= _generation(leaf, inode_item); > - =C2=A0 =C2=A0 =C2=A0 BTRFS_I(inode)->sequence =3D btrfs_inode_seque= nce(leaf, inode_item); > + =C2=A0 =C2=A0 =C2=A0 inode->i_version =3D btrfs_inode_sequence(leaf= , inode_item); > =C2=A0 =C2=A0 =C2=A0 =C2=A0inode->i_generation =3D BTRFS_I(inode)->ge= neration; > =C2=A0 =C2=A0 =C2=A0 =C2=A0inode->i_rdev =3D 0; > =C2=A0 =C2=A0 =C2=A0 =C2=A0rdev =3D btrfs_inode_rdev(leaf, inode_item= ); > @@ -2594,7 +2594,7 @@ static void fill_inode_item(struct btrfs_trans_= handle *trans, > > =C2=A0 =C2=A0 =C2=A0 =C2=A0btrfs_set_inode_nbytes(leaf, item, inode_g= et_bytes(inode)); > =C2=A0 =C2=A0 =C2=A0 =C2=A0btrfs_set_inode_generation(leaf, item, BTR= =46S_I(inode)->generation); > - =C2=A0 =C2=A0 =C2=A0 btrfs_set_inode_sequence(leaf, item, BTRFS_I(i= node)->sequence); > + =C2=A0 =C2=A0 =C2=A0 btrfs_set_inode_sequence(leaf, item, inode->i_= version); > =C2=A0 =C2=A0 =C2=A0 =C2=A0btrfs_set_inode_transid(leaf, item, trans-= >transid); > =C2=A0 =C2=A0 =C2=A0 =C2=A0btrfs_set_inode_rdev(leaf, item, inode->i_= rdev); > =C2=A0 =C2=A0 =C2=A0 =C2=A0btrfs_set_inode_flags(leaf, item, BTRFS_I(= inode)->flags); > @@ -6884,7 +6884,6 @@ struct inode *btrfs_alloc_inode(struct super_bl= ock *sb) > =C2=A0 =C2=A0 =C2=A0 =C2=A0ei->root =3D NULL; > =C2=A0 =C2=A0 =C2=A0 =C2=A0ei->space_info =3D NULL; > =C2=A0 =C2=A0 =C2=A0 =C2=A0ei->generation =3D 0; > - =C2=A0 =C2=A0 =C2=A0 ei->sequence =3D 0; > =C2=A0 =C2=A0 =C2=A0 =C2=A0ei->last_trans =3D 0; > =C2=A0 =C2=A0 =C2=A0 =C2=A0ei->last_sub_trans =3D 0; > =C2=A0 =C2=A0 =C2=A0 =C2=A0ei->logged_trans =3D 0; > diff --git a/fs/btrfs/super.c b/fs/btrfs/super.c > index 54e7ee9..ee1bb31 100644 > --- a/fs/btrfs/super.c > +++ b/fs/btrfs/super.c > @@ -770,7 +770,7 @@ static int btrfs_fill_super(struct super_block *s= b, > =C2=A0#ifdef CONFIG_BTRFS_FS_POSIX_ACL > =C2=A0 =C2=A0 =C2=A0 =C2=A0sb->s_flags |=3D MS_POSIXACL; > =C2=A0#endif > - > + =C2=A0 =C2=A0 =C2=A0 sb->s_flags |=3D MS_I_VERSION; > =C2=A0 =C2=A0 =C2=A0 =C2=A0err =3D open_ctree(sb, fs_devices, (char *= )data); > =C2=A0 =C2=A0 =C2=A0 =C2=A0if (err) { > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0printk("btrfs:= open_ctree failed\n"); > -- > 1.7.5.2 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-btrfs= " in > the body of a message to majordomo@vger.kernel.org > More majordomo info at =C2=A0http://vger.kernel.org/majordomo-info.ht= ml BTW. 1. where is BTRFS devel git tree? 2. when this is coming to mainline? - Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" = in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] Btrfs: use i_version instead of our own sequence 2012-04-12 13:22 ` Kasatkin, Dmitry @ 2012-04-12 13:31 ` Josef Bacik 2012-04-12 21:41 ` Wiki update request: source repo page Was: " Duncan 0 siblings, 1 reply; 10+ messages in thread From: Josef Bacik @ 2012-04-12 13:31 UTC (permalink / raw) To: Kasatkin, Dmitry; +Cc: Josef Bacik, linux-btrfs On Thu, Apr 12, 2012 at 04:22:26PM +0300, Kasatkin, Dmitry wrote: > On Mon, Apr 9, 2012 at 6:53 PM, Josef Bacik <josef@redhat.com> wrote: > > We've been keeping around the inode sequence number in hopes that s= omebody > > would use it, but nobody uses it and people actually use i_version = which > > serves the same purpose, so use i_version where we used the incore = inode's > > sequence number and that way the sequence is updated properly acros= s the > > board, and not just in file write. =A0Thanks, > > > > Signed-off-by: Josef Bacik <josef@redhat.com> > > --- > > =A0fs/btrfs/btrfs_inode.h =A0 | =A0 =A03 --- > > =A0fs/btrfs/delayed-inode.c | =A0 =A04 ++-- > > =A0fs/btrfs/file.c =A0 =A0 =A0 =A0 =A0| =A0 =A01 - > > =A0fs/btrfs/inode.c =A0 =A0 =A0 =A0 | =A0 =A05 ++--- > > =A0fs/btrfs/super.c =A0 =A0 =A0 =A0 | =A0 =A02 +- > > =A05 files changed, 5 insertions(+), 10 deletions(-) > > > > diff --git a/fs/btrfs/btrfs_inode.h b/fs/btrfs/btrfs_inode.h > > index 9b9b15f..3771b85 100644 > > --- a/fs/btrfs/btrfs_inode.h > > +++ b/fs/btrfs/btrfs_inode.h > > @@ -83,9 +83,6 @@ struct btrfs_inode { > > =A0 =A0 =A0 =A0 */ > > =A0 =A0 =A0 =A0u64 generation; > > > > - =A0 =A0 =A0 /* sequence number for NFS changes */ > > - =A0 =A0 =A0 u64 sequence; > > - > > =A0 =A0 =A0 =A0/* > > =A0 =A0 =A0 =A0 * transid of the trans_handle that last modified th= is inode > > =A0 =A0 =A0 =A0 */ > > diff --git a/fs/btrfs/delayed-inode.c b/fs/btrfs/delayed-inode.c > > index 03e3748..bcd40c7 100644 > > --- a/fs/btrfs/delayed-inode.c > > +++ b/fs/btrfs/delayed-inode.c > > @@ -1706,7 +1706,7 @@ static void fill_stack_inode_item(struct btrf= s_trans_handle *trans, > > =A0 =A0 =A0 =A0btrfs_set_stack_inode_nbytes(inode_item, inode_get_b= ytes(inode)); > > =A0 =A0 =A0 =A0btrfs_set_stack_inode_generation(inode_item, > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 BTRFS_I(inode)->generation); > > - =A0 =A0 =A0 btrfs_set_stack_inode_sequence(inode_item, BTRFS_I(in= ode)->sequence); > > + =A0 =A0 =A0 btrfs_set_stack_inode_sequence(inode_item, inode->i_v= ersion); > > =A0 =A0 =A0 =A0btrfs_set_stack_inode_transid(inode_item, trans->tra= nsid); > > =A0 =A0 =A0 =A0btrfs_set_stack_inode_rdev(inode_item, inode->i_rdev= ); > > =A0 =A0 =A0 =A0btrfs_set_stack_inode_flags(inode_item, BTRFS_I(inod= e)->flags); > > @@ -1754,7 +1754,7 @@ int btrfs_fill_inode(struct inode *inode, u32= *rdev) > > =A0 =A0 =A0 =A0set_nlink(inode, btrfs_stack_inode_nlink(inode_item)= ); > > =A0 =A0 =A0 =A0inode_set_bytes(inode, btrfs_stack_inode_nbytes(inod= e_item)); > > =A0 =A0 =A0 =A0BTRFS_I(inode)->generation =3D btrfs_stack_inode_gen= eration(inode_item); > > - =A0 =A0 =A0 BTRFS_I(inode)->sequence =3D btrfs_stack_inode_sequen= ce(inode_item); > > + =A0 =A0 =A0 inode->i_version =3D btrfs_stack_inode_sequence(inode= _item); > > =A0 =A0 =A0 =A0inode->i_rdev =3D 0; > > =A0 =A0 =A0 =A0*rdev =3D btrfs_stack_inode_rdev(inode_item); > > =A0 =A0 =A0 =A0BTRFS_I(inode)->flags =3D btrfs_stack_inode_flags(in= ode_item); > > diff --git a/fs/btrfs/file.c b/fs/btrfs/file.c > > index 431b565..f0da02b 100644 > > --- a/fs/btrfs/file.c > > +++ b/fs/btrfs/file.c > > @@ -1404,7 +1404,6 @@ static ssize_t btrfs_file_aio_write(struct ki= ocb *iocb, > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0mutex_unlock(&inode->i_mutex); > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0goto out; > > =A0 =A0 =A0 =A0} > > - =A0 =A0 =A0 BTRFS_I(inode)->sequence++; > > > > =A0 =A0 =A0 =A0start_pos =3D round_down(pos, root->sectorsize); > > =A0 =A0 =A0 =A0if (start_pos > i_size_read(inode)) { > > diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c > > index 7a084fb..7d3dd2f 100644 > > --- a/fs/btrfs/inode.c > > +++ b/fs/btrfs/inode.c > > @@ -2510,7 +2510,7 @@ static void btrfs_read_locked_inode(struct in= ode *inode) > > > > =A0 =A0 =A0 =A0inode_set_bytes(inode, btrfs_inode_nbytes(leaf, inod= e_item)); > > =A0 =A0 =A0 =A0BTRFS_I(inode)->generation =3D btrfs_inode_generatio= n(leaf, inode_item); > > - =A0 =A0 =A0 BTRFS_I(inode)->sequence =3D btrfs_inode_sequence(lea= f, inode_item); > > + =A0 =A0 =A0 inode->i_version =3D btrfs_inode_sequence(leaf, inode= _item); > > =A0 =A0 =A0 =A0inode->i_generation =3D BTRFS_I(inode)->generation; > > =A0 =A0 =A0 =A0inode->i_rdev =3D 0; > > =A0 =A0 =A0 =A0rdev =3D btrfs_inode_rdev(leaf, inode_item); > > @@ -2594,7 +2594,7 @@ static void fill_inode_item(struct btrfs_tran= s_handle *trans, > > > > =A0 =A0 =A0 =A0btrfs_set_inode_nbytes(leaf, item, inode_get_bytes(i= node)); > > =A0 =A0 =A0 =A0btrfs_set_inode_generation(leaf, item, BTRFS_I(inode= )->generation); > > - =A0 =A0 =A0 btrfs_set_inode_sequence(leaf, item, BTRFS_I(inode)->= sequence); > > + =A0 =A0 =A0 btrfs_set_inode_sequence(leaf, item, inode->i_version= ); > > =A0 =A0 =A0 =A0btrfs_set_inode_transid(leaf, item, trans->transid); > > =A0 =A0 =A0 =A0btrfs_set_inode_rdev(leaf, item, inode->i_rdev); > > =A0 =A0 =A0 =A0btrfs_set_inode_flags(leaf, item, BTRFS_I(inode)->fl= ags); > > @@ -6884,7 +6884,6 @@ struct inode *btrfs_alloc_inode(struct super_= block *sb) > > =A0 =A0 =A0 =A0ei->root =3D NULL; > > =A0 =A0 =A0 =A0ei->space_info =3D NULL; > > =A0 =A0 =A0 =A0ei->generation =3D 0; > > - =A0 =A0 =A0 ei->sequence =3D 0; > > =A0 =A0 =A0 =A0ei->last_trans =3D 0; > > =A0 =A0 =A0 =A0ei->last_sub_trans =3D 0; > > =A0 =A0 =A0 =A0ei->logged_trans =3D 0; > > diff --git a/fs/btrfs/super.c b/fs/btrfs/super.c > > index 54e7ee9..ee1bb31 100644 > > --- a/fs/btrfs/super.c > > +++ b/fs/btrfs/super.c > > @@ -770,7 +770,7 @@ static int btrfs_fill_super(struct super_block = *sb, > > =A0#ifdef CONFIG_BTRFS_FS_POSIX_ACL > > =A0 =A0 =A0 =A0sb->s_flags |=3D MS_POSIXACL; > > =A0#endif > > - > > + =A0 =A0 =A0 sb->s_flags |=3D MS_I_VERSION; > > =A0 =A0 =A0 =A0err =3D open_ctree(sb, fs_devices, (char *)data); > > =A0 =A0 =A0 =A0if (err) { > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0printk("btrfs: open_ctree failed\n")= ; > > -- > > 1.7.5.2 > > > > -- > > To unsubscribe from this list: send the line "unsubscribe linux-btr= fs" in > > the body of a message to majordomo@vger.kernel.org > > More majordomo info at =A0http://vger.kernel.org/majordomo-info.htm= l >=20 > BTW. > 1. where is BTRFS devel git tree? > 2. when this is coming to mainline? >=20 There's a bunch, my personal tree with just my patches is here git://git.kernel.org/pub/scm/linux/kernel/git/josef/btrfs-work.git a tree with all outstanding mailinglist patches is here git://git.kernel.org/pub/scm/linux/kernel/git/josef/btrfs-next.git and Chris's tree which is where all things go through to get to mainlin= e is here git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git It will probably be in the next merge window. Thanks, Josef -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" = in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 10+ messages in thread
* Wiki update request: source repo page Was: [PATCH] Btrfs: use i_version instead of our own sequence 2012-04-12 13:31 ` Josef Bacik @ 2012-04-12 21:41 ` Duncan 2012-04-12 21:55 ` Hugo Mills 0 siblings, 1 reply; 10+ messages in thread From: Duncan @ 2012-04-12 21:41 UTC (permalink / raw) To: linux-btrfs Josef Bacik posted on Thu, 12 Apr 2012 09:31:07 -0400 as excerpted: >> BTW. >> 1. where is BTRFS devel git tree? >> 2. when this is coming to mainline? >> >> > There's a bunch, my personal tree with just my patches is here > > git://git.kernel.org/pub/scm/linux/kernel/git/josef/btrfs-work.git > > a tree with all outstanding mailinglist patches is here > > git://git.kernel.org/pub/scm/linux/kernel/git/josef/btrfs-next.git > > and Chris's tree which is where all things go through to get to mainline > is here > > git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git > > It will probably be in the next merge window. Thanks, Could this list be added to the btrfs wiki, source repositories page? http://btrfs.ipv5.de/index.php?title=Btrfs_source_repositories While there, please review the dkms information: 0) At least a paragraph actually describing what dkms is/does would be extremely useful. A link to another page on the topic or to an external dkms resource for more information is probably in order as well. 1) Near the top of the dkms section, under "You have a very recent kernel", the for instance says dkms doesn't work with recent kernels, but then backporting is mentioned. So you want to use it if you have a very recent kernel, but it doesn't work with recent kernels and backporting is needed? WTF? 2) Is Chris's tree STILL based on old 2.6.32 without further updates except to btrfs? If so, the link to it in the earlier btrfs kernel module git repository section should probably have a BIG WARNING TO THAT EFFECT, instead of simply saying it downloads a complete Linux kernel tree. 3) Further down there's a step that says Patch version script, noting 2.6.27, which is older still. Has cmason merged that patch? 4) The instructions appear to assume a kernel module an initr* based setup. What about people who configure and build a custom monolithic kernel, with module loading disabled? -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Wiki update request: source repo page Was: [PATCH] Btrfs: use i_version instead of our own sequence 2012-04-12 21:41 ` Wiki update request: source repo page Was: " Duncan @ 2012-04-12 21:55 ` Hugo Mills 2012-04-12 22:56 ` Duncan 0 siblings, 1 reply; 10+ messages in thread From: Hugo Mills @ 2012-04-12 21:55 UTC (permalink / raw) To: Duncan; +Cc: linux-btrfs [-- Attachment #1: Type: text/plain, Size: 3106 bytes --] On Thu, Apr 12, 2012 at 09:41:17PM +0000, Duncan wrote: > Josef Bacik posted on Thu, 12 Apr 2012 09:31:07 -0400 as excerpted: > > >> BTW. > >> 1. where is BTRFS devel git tree? > >> 2. when this is coming to mainline? > >> > >> > > There's a bunch, my personal tree with just my patches is here > > > > git://git.kernel.org/pub/scm/linux/kernel/git/josef/btrfs-work.git > > > > a tree with all outstanding mailinglist patches is here > > > > git://git.kernel.org/pub/scm/linux/kernel/git/josef/btrfs-next.git > > > > and Chris's tree which is where all things go through to get to mainline > > is here > > > > git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git > > > > It will probably be in the next merge window. Thanks, > > > Could this list be added to the btrfs wiki, source repositories page? Well, it _is_ a wiki... Knock yourself out. > http://btrfs.ipv5.de/index.php?title=Btrfs_source_repositories > > While there, please review the dkms information: [snip dkms] > 2) Is Chris's tree STILL based on old 2.6.32 without further updates > except to btrfs? If so, the link to it in the earlier btrfs kernel > module git repository section should probably have a BIG WARNING TO THAT > EFFECT, instead of simply saying it downloads a complete Linux kernel > tree. No, it's generally based on some recent linux-kernel (usually not more than one revision out). Possibly some instructions on using git merge to combine Chris's tree with Linus's would be useful (although I think it's generally assumed that if you're using git to pull some arbitrary repo to build from that you know how to drive git to that degree anyway). > 3) Further down there's a step that says Patch version script, noting > 2.6.27, which is older still. Has cmason merged that patch? > > 4) The instructions appear to assume a kernel module an initr* based > setup. What about people who configure and build a custom monolithic > kernel, with module loading disabled? Then in general, they're stuffed. If you want to mount a multi-device filesystem, you have to run btrfs dev scan before it's mounted. If that filesystem is your root filesystem, then you have to do it before root is mounted. This requires an initramfs/initrd. It is possible to supply a full list of explicit device names for the root FS to the kernel at boot time with the device= mount parameter, but this is unreliable at best. We certainly had a very hard time getting it to work last time the issue came up on IRC. The general advice is -- use a single-device root filesystem, or an initramfs. These are simple, supported, and will generally get good help. Any other configuration will cause you to be told to use an initramfs. So far, I've not heard any concrete reason why one shouldn't be used except "ooh, I don't understand them, and they're scary!". Hugo. -- === Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk === PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk --- This year, I'm giving up Lent. --- [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 190 bytes --] ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Wiki update request: source repo page Was: [PATCH] Btrfs: use i_version instead of our own sequence 2012-04-12 21:55 ` Hugo Mills @ 2012-04-12 22:56 ` Duncan 2012-04-13 13:16 ` Hugo Mills 0 siblings, 1 reply; 10+ messages in thread From: Duncan @ 2012-04-12 22:56 UTC (permalink / raw) To: linux-btrfs Hugo Mills posted on Thu, 12 Apr 2012 22:55:46 +0100 as excerpted: > On Thu, Apr 12, 2012 at 09:41:17PM +0000, Duncan wrote: >> 4) The instructions appear to assume a kernel module an initr* based >> setup. What about people who configure and build a custom monolithic >> kernel, with module loading disabled? > > Then in general, they're stuffed. > > If you want to mount a multi-device filesystem, you have to run > btrfs dev scan before it's mounted. If that filesystem is your root > filesystem, then you have to do it before root is mounted. This requires > an initramfs/initrd. > > It is possible to supply a full list of explicit device names for > the root FS to the kernel at boot time with the device= mount parameter, > but this is unreliable at best. We certainly had a very hard time > getting it to work last time the issue came up on IRC. > > The general advice is -- use a single-device root filesystem, or an > initramfs. These are simple, supported, and will generally get good > help. Any other configuration will cause you to be told to use an > initramfs. So far, I've not heard any concrete reason why one shouldn't > be used except "ooh, I don't understand them, and they're scary!". FWIW, device names appear to be reasonably stable, here. Stable enough that I currently have this built into the kernel as part of my kernel command line: md=3,/dev/sda6,/dev/sdb6,/dev/sdc6,/dev/sdd6 root=/dev/md3p1 When I need to override that to mount the primary backup/recovery root, this as part of grub2's linux line extends/overrides the kernel builtin: md=9,/dev/sda12,/dev/sdb12,/dev/sdc12,/dev/sdd12 root=/dev/md9p1 When I boot from thumbdrive or otherwise might trigger device reordering, grub's interactivity allows me to find the correct mds and substitute device names as appropriate. And yes, if you're wondering, init=/bin/bash is tested and known to work, too. =:^) I don't see why btrfs would have additional kernel device naming or finding problems that md doesn't already have. So while I'd agree that multi-device noinitr* btrfs builtin might not be appropriate as a general distro-wide solution, it does seem quite reasonable (here) for sysadmins familiar enough with their own systems to have custom-built no-module-loading kernels in general, to be able to do the same with btrfs. That's one of a couple reasons I don't use lvm2, as well. Both lvm2 and an initr* add complexity and thus recovery failure risk due to admin fat- fingering or failure to anticipate and test all permutations of failure mode, for little or no gain in my current deployments. Because lvm2 requires an initr* to handle root, it's TWO such layers of additional complexity to test the failure modes for and be prepared to deal with at recovery time. The added complexity and risk is simply not a reasonable tradeoff, for me, and I sleep better with a tested confidence in my disaster recovery abilities. =:^) -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Wiki update request: source repo page Was: [PATCH] Btrfs: use i_version instead of our own sequence 2012-04-12 22:56 ` Duncan @ 2012-04-13 13:16 ` Hugo Mills 2012-04-13 18:48 ` Duncan 0 siblings, 1 reply; 10+ messages in thread From: Hugo Mills @ 2012-04-13 13:16 UTC (permalink / raw) To: Duncan; +Cc: linux-btrfs [-- Attachment #1: Type: text/plain, Size: 4611 bytes --] On Thu, Apr 12, 2012 at 10:56:00PM +0000, Duncan wrote: > Hugo Mills posted on Thu, 12 Apr 2012 22:55:46 +0100 as excerpted: > > The general advice is -- use a single-device root filesystem, or an > > initramfs. These are simple, supported, and will generally get good > > help. Any other configuration will cause you to be told to use an > > initramfs. So far, I've not heard any concrete reason why one shouldn't > > be used except "ooh, I don't understand them, and they're scary!". > > FWIW, device names appear to be reasonably stable, here. Stable enough > that I currently have this built into the kernel as part of my kernel > command line: That's all well and good for you, but my point is that in the general case, device names are *not* stable, and the kernel does *not* claim to guarantee this. If you assume that they are stable, and your system breaks as a result, then you get to keep both pieces. Your choice, but your risk as well. The recommendation for a stable reliable system is to run btrfs dev scan before mounting a btrfs filesystem. > md=3,/dev/sda6,/dev/sdb6,/dev/sdc6,/dev/sdd6 root=/dev/md3p1 > > When I need to override that to mount the primary backup/recovery root, > this as part of grub2's linux line extends/overrides the kernel builtin: > > md=9,/dev/sda12,/dev/sdb12,/dev/sdc12,/dev/sdd12 root=/dev/md9p1 So you're doing the same thing as btrfs's "device=" mount option. Again, if this works, all well and good, but it'll break if devices move around, requiring the manual step. If you want to avoid that and have it all Just Work, use an initrd (for both MD and btrfs). > When I boot from thumbdrive or otherwise might trigger device reordering, > grub's interactivity allows me to find the correct mds and substitute > device names as appropriate. And yes, if you're wondering, > init=/bin/bash is tested and known to work, too. =:^) > > I don't see why btrfs would have additional kernel device naming or > finding problems that md doesn't already have. As far as I recall, MD also requires userspace help in order to reassemble a device correctly, except when v0.9 superblocks are used (which have limitations on the set of other features they support). > So while I'd agree that multi-device noinitr* btrfs builtin might not be > appropriate as a general distro-wide solution, it does seem quite > reasonable (here) for sysadmins familiar enough with their own systems to > have custom-built no-module-loading kernels in general, to be able to do > the same with btrfs. I disagree. You could conceivably get the kernel to scan every single block device it knows about as the device is discovered, but then the kernel would take unnecessarily long to boot (consider something with a stack of DVD drives -- you'd have to wait for each one to spin up before scanning it). If you were to restrict the set of devices scanned, you're putting policy into the kernel, which would get rejected pretty much instantly by anyone upstream. > That's one of a couple reasons I don't use lvm2, as well. Both lvm2 and > an initr* add complexity and thus recovery failure risk due to admin fat- > fingering or failure to anticipate and test all permutations of failure > mode, for little or no gain in my current deployments. Again, that's good for you, but all such attempts should be viewed as unreliable workarounds, not as recommended and supported approaches. > Because lvm2 requires an initr* to handle root, it's TWO such > layers of additional complexity to test the failure modes for and be > prepared to deal with at recovery time. The added complexity and > risk is simply not a reasonable tradeoff, for me, and I sleep better > with a tested confidence in my disaster recovery abilities. =:^) I have had my initrd (for root on LVM on MD) fail precisely once in 8 years or so, and that was down to my upgrading some LVM tools manually and not rebuilding the initrd. If you stick to your distribution's packages (at least for boot-critical things), then I would think it highly unlikely you'll end up with a system that fails to boot. If you muck around with it manually and it breaks, then I would suggest you treat it as a learning experience. Hugo. -- === Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk === PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk --- Our so-called leaders speak/with words they try to jail ya/ --- They subjugate the meek/but it's the rhetoric of failure. [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 190 bytes --] ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Wiki update request: source repo page Was: [PATCH] Btrfs: use i_version instead of our own sequence 2012-04-13 13:16 ` Hugo Mills @ 2012-04-13 18:48 ` Duncan 2012-04-13 20:03 ` cwillu 0 siblings, 1 reply; 10+ messages in thread From: Duncan @ 2012-04-13 18:48 UTC (permalink / raw) To: linux-btrfs Hugo Mills posted on Fri, 13 Apr 2012 14:16:32 +0100 as excerpted: > On Thu, Apr 12, 2012 at 10:56:00PM +0000, Duncan wrote: >> Hugo Mills posted on Thu, 12 Apr 2012 22:55:46 +0100 as excerpted: >> > The general advice is -- use a single-device root filesystem, or an >> > initramfs. These are simple, supported, and will generally get good >> > help. Any other configuration will cause you to be told to use an >> > initramfs. So far, I've not heard any concrete reason why one >> > shouldn't be used except "ooh, I don't understand them, and they're >> > scary!". >> >> FWIW, device names appear to be reasonably stable, here. Stable enough >> that I currently have this built into the kernel as part of my kernel >> command line: > > That's all well and good for you, but my point is that in the > general case, device names are *not* stable, and the kernel does *not* > claim to guarantee this. If you assume that they are stable, and your > system breaks as a result, then you get to keep both pieces. Your > choice, but your risk as well. The recommendation for a stable reliable > system is to run btrfs dev scan before mounting a btrfs filesystem. BTW, I don't believe I've thanked you for the replies, yet. Thanks, and I don't disagree with the rest. I guess I generally agree here, too... with /generally/ stressed. But the wiki should cover more than the default, "general" case. Meanwhile [kernel command line] ... >> md=3,/dev/sda6,/dev/sdb6,/dev/sdc6,/dev/sdd6 root=/dev/md3p1 > So you're doing the same thing as btrfs's "device=" mount option. Same general thing, yes. > Again, if this works, all well and good, but it'll break if devices move > around, requiring the manual step. If you want to avoid that and have it > all Just Work, use an initrd (for both MD and btrfs). Obviously, for systems where it all moves around at every boot, this isn't going to be a very useful alternative, I'll agree. But that's not the case on a lot of hardware. And the trouble with "just works" isn't when it does INDEED "just work", but when it doesn't. In that case, the admin needs to be comfortable enough with the system and his understanding of it to get things back into operational condition. The more layers of unnecessary complexity (like a shouldn't be necessary initr*) there are, the more difficult that "grok the system well enough to be reasonably confident in one's ability to restore it" status is to achieve, and the higher the risk of failure, should the admin's disaster recovery skills actually be needed. > As far as I recall, MD also requires userspace help in order to > reassemble a device correctly, except when v0.9 superblocks are used > (which have limitations on the set of other features they support). I've read that is true, altho I've not tested it, I've simply gone with 0.90 superblocks, because here, the cost of 0.90 is rather low compared to the benefits of no-userspace-required assembly from kernel commandline and detected data. If btrfs (or md) should lose that ability, it'd be a shame. >> So while I'd agree that multi-device noinitr* btrfs builtin might not >> be appropriate as a general distro-wide solution, it does seem quite >> reasonable (here) for sysadmins familiar enough with their own systems >> to have custom-built no-module-loading kernels in general, to be able >> to do the same with btrfs. > > I disagree. You could conceivably get the kernel to scan every > single block device it knows about as the device is discovered, but then > the kernel would take unnecessarily long to boot (consider something > with a stack of DVD drives -- you'd have to wait for each one to spin up > before scanning it). If you were to restrict the set of devices scanned, > you're putting policy into the kernel, which would get rejected pretty > much instantly by anyone upstream. No need to have the kernel scan everything (certainly not by default) OR limit policy... while still retaining flexibility. Simply keep the ability to have it specified on the kernel commandline, for systems with a stable enough device layout that it works. Actually, with a flexible enough bootloader, and grub2 certainly seems at least close to that already, as with its modules it already supports both mdraid and lvm2 as well as btrfs (and apparently zfs as well), any scanning ability as well as site configuration and policy, could be and already is to some degree, built into the bootloader's modules, as long as the kernel commandline (or other similar mechanism) remains available to handle the necessary data passed to it from the bootloader. > I have had my initrd (for root on LVM on MD) fail precisely once in > 8 years or so, and that was down to my upgrading some LVM tools manually > and not rebuilding the initrd. If you stick to your distribution's > packages (at least for boot-critical things), then I would think it > highly unlikely you'll end up with a system that fails to boot. If you > muck around with it manually and it breaks, then I would suggest you > treat it as a learning experience. Stick to a distro's packages? How are people only running distro packages supposed to run the patches they're asked to test on the list, talk the distro package maintainer into including possibly one-shot debugging patches into a new general rollout? True, some distros are packaging and even supporting btrfs already, and some users, their own admins, are reckless enough to dive right in, without checking project status, or the wiki, or the list... but that can hardly be the /target/ audience for btrfs at this point, right? -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Wiki update request: source repo page Was: [PATCH] Btrfs: use i_version instead of our own sequence 2012-04-13 18:48 ` Duncan @ 2012-04-13 20:03 ` cwillu 2012-04-13 21:55 ` Duncan 0 siblings, 1 reply; 10+ messages in thread From: cwillu @ 2012-04-13 20:03 UTC (permalink / raw) To: Duncan; +Cc: linux-btrfs On Fri, Apr 13, 2012 at 12:48 PM, Duncan <1i5t5.duncan@cox.net> wrote: > Hugo Mills posted on Fri, 13 Apr 2012 14:16:32 +0100 as excerpted: > >> On Thu, Apr 12, 2012 at 10:56:00PM +0000, Duncan wrote: >>> Hugo Mills posted on Thu, 12 Apr 2012 22:55:46 +0100 as excerpted: >>> > The general advice is -- use a single-device root filesystem, or = an >>> > initramfs. These are simple, supported, and will generally get go= od >>> > help. Any other configuration will cause you to be told to use an >>> > initramfs. So far, I've not heard any concrete reason why one >>> > shouldn't be used except "ooh, I don't understand them, and they'= re >>> > scary!". >>> >>> FWIW, device names appear to be reasonably stable, here. =C2=A0Stab= le enough >>> that I currently have this built into the kernel as part of my kern= el >>> command line: >> >> That's all well and good for you, but my point is that in the >> general case, device names are *not* stable, and the kernel does *no= t* >> claim to guarantee this. If you assume that they are stable, and you= r >> system breaks as a result, then you get to keep both pieces. Your >> choice, but your risk as well. The recommendation for a stable relia= ble >> system is to run btrfs dev scan before mounting a btrfs filesystem. > > BTW, I don't believe I've thanked you for the replies, yet. =C2=A0Tha= nks, and > I don't disagree with the rest. > > I guess I generally agree here, too... with /generally/ stressed. =C2= =A0But > the wiki should cover more than the default, "general" case. > > Meanwhile [kernel command line] ... > >>> md=3D3,/dev/sda6,/dev/sdb6,/dev/sdc6,/dev/sdd6 root=3D/dev/md3p1 > >> So you're doing the same thing as btrfs's "device=3D" mount option. > > Same general thing, yes. > >> Again, if this works, all well and good, but it'll break if devices = move >> around, requiring the manual step. If you want to avoid that and hav= e it >> all Just Work, use an initrd (for both MD and btrfs). > > Obviously, for systems where it all moves around at every boot, this > isn't going to be a very useful alternative, I'll agree. =C2=A0But th= at's not > the case on a lot of hardware. > > And the trouble with "just works" isn't when it does INDEED "just wor= k", > but when it doesn't. =C2=A0In that case, the admin needs to be comfor= table > enough with the system and his understanding of it to get things back > into operational condition. =C2=A0The more layers of unnecessary comp= lexity > (like a shouldn't be necessary initr*) there are, the more difficult = that > "grok the system well enough to be reasonably confident in one's abil= ity > to restore it" status is to achieve, and the higher the risk of failu= re, > should the admin's disaster recovery skills actually be needed. The fact is that you _don't_ know that your device names aren't going to change one day, any more than a generation of developers who only worked with ext3 knew that "fsync is expensive and all you really need is the atomic guarantee of mv". [snip] > Stick to a distro's packages? > > How are people only running distro packages supposed to run the patch= es > they're asked to test on the list, talk the distro package maintainer > into including possibly one-shot debugging patches into a new general > rollout? On debian derivatives at least, creating a distro packaged kernel from a git checkout is a single, fairly short, command. And the logic to create the initramfs is separate from that, triggered when a kernel is installed (and which works even if you just installed a kernel by copying the bzimage to /boot). I'd be surprised if it was much different on any other distro. Everyone needs to start somewhere, but it's not unreasonable to expect an admin to understand how their distro does things, and where to find answers when they don't know, and to verify that their knowledge is correct. The middle of a disaster recovery should not be the first time you've tried a recovery. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" = in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Wiki update request: source repo page Was: [PATCH] Btrfs: use i_version instead of our own sequence 2012-04-13 20:03 ` cwillu @ 2012-04-13 21:55 ` Duncan 0 siblings, 0 replies; 10+ messages in thread From: Duncan @ 2012-04-13 21:55 UTC (permalink / raw) To: linux-btrfs cwillu posted on Fri, 13 Apr 2012 14:03:38 -0600 as excerpted: > The fact is that you _don't_ know that your device names aren't going to > change one day, any more than a generation of developers who only worked > with ext3 knew that "fsync is expensive and all you really need is the > atomic guarantee of mv". What I /do/ know is that such changes will be due to either (1) kernel upgrades or (2) hardware changes (planned upgrades or unpredicted failure). Both factors can be mitigated with redundant layers of fallback and dynamic reconfiguration. Regardless of what brings those device names, a fallback to an earlier kernel, or a different device, or a bit of manual grub commandline new device location detection and according alteration of the grub-passed kernel command line so I can boot and make the necessary permanent config changes, is all it'll take to change that. And as an admin working with stuff directly within my reach to fix when necessary, unlike that generation of developers on ext3 with expensive fsync, once it's out of my reach to directly manipulate for a fix, it's no longer something I need to worry about. Granted, btrfs and distro devs have to worry about products out of their direct reach to fix, but that doesn't mean they have to take the tools away (or even simply hide them) from those that can and do put them to use. > Everyone needs to start somewhere, but it's not unreasonable to expect > an admin to understand how their distro does things, and where to find > answers when they don't know, and to verify that their knowledge is > correct. The middle of a disaster recovery should not be the first time > you've tried a recovery. Agreed. That's why a prudent admin continually scans the radar for incoming, as well as having tested fallbacks for the unexpected. Either that, or as I was at one point, they don't have the knowledge or experience yet, but are willing to risk loss of data and a new install, in ordered to get that knowledge and experience. I remember being in that group myself, and to a certain extent, I'm still a part of it. After all, that level of risk and the knowledge and experienced gained from it is part of the pull of pre-releases, live-git kernels, and experimental filesystems, in the first place. But that doesn't mean I don't try to control that risk by building on knowledge and experience I already have to limit the risk stack at other levels. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2012-04-13 21:55 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2012-04-09 15:53 [PATCH] Btrfs: use i_version instead of our own sequence Josef Bacik 2012-04-12 13:22 ` Kasatkin, Dmitry 2012-04-12 13:31 ` Josef Bacik 2012-04-12 21:41 ` Wiki update request: source repo page Was: " Duncan 2012-04-12 21:55 ` Hugo Mills 2012-04-12 22:56 ` Duncan 2012-04-13 13:16 ` Hugo Mills 2012-04-13 18:48 ` Duncan 2012-04-13 20:03 ` cwillu 2012-04-13 21:55 ` Duncan
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.