headers
Dave Chinner | 1 Feb 2009 02:40

Re: Warning and BUG with btrfs and corrupted image

On Mon, Jan 26, 2009 at 05:27:11PM +0100, Pavel Machek wrote:
> On Wed 2009-01-21 15:00:42, Dave Chinner wrote:
> > On Tue, Jan 20, 2009 at 11:20:19PM +0100, Pavel Machek wrote:
> > > On Tue 2009-01-20 08:28:29, Christoph Hellwig wrote:
> > > > I think that was the issue with the debug builds.  If you do this
> > > > testing always do it without CONFIG_XFS_DEBUG set as with that option
> > > > we intentionally panic on detected disk corruptions.
> > > 
> > > Uhuh, *_DEBUG options are not supposed to make kernel less
> > > stable/robust. Should that crashing functionality be guarded with
> > > command line option or something? ext2 has errors=panic mount
> > > option...
> > 
> > No, it's a debugging option that is described as:
> > 
> > 	"Say N unless you are an XFS developer, or you play one on TV."
> > 
> > Seriously, if you aren't trying to develop XFS stuff then *don't turn it
> > on*.
> 
> What about this, then?

....

> +	  Turning this option on will result in kernel panicking any time
> +	  it detects on-disk corruption.

Thin end of a wedge. There's a couple of thousand conditions that
CONFIG_XFS_DEBUG introduces kernel panics on:
(Continue reading)

Permalink | Reply | 14 comments |
headers
Chris Ball | 1 Feb 2009 04:48
Favicon
Gravatar

[PATCH] btrfs: Handle SGID bit when creating inodes

Before this patch, new files/dirs would ignore the SGID bit on their
parent directory and always be owned by the creating user's uid/gid.

Signed-off-by: Chris Ball <cjb <at> laptop.org>
---
 fs/btrfs/inode.c |    9 ++++++++-
 1 files changed, 8 insertions(+), 1 deletions(-)

diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
index ebd7d6c..ce25bb3 100644
--- a/fs/btrfs/inode.c
+++ b/fs/btrfs/inode.c
 <at>  <at>  -3470,7 +3470,14  <at>  <at>  static struct inode *btrfs_new_inode(struct btrfs_trans_handle *trans,
 		root->highest_inode = objectid;

 	inode->i_uid = current_fsuid();
-	inode->i_gid = current_fsgid();
+
+	if (dir->i_mode & S_ISGID) {
+		inode->i_gid = dir->i_gid;
+		if (S_ISDIR(mode))
+			mode |= S_ISGID;
+	} else
+		inode->i_gid = current_fsgid();
+
 	inode->i_mode = mode;
 	inode->i_ino = objectid;
 	inode_set_bytes(inode, 0);
--

-- 
1.6.1.2
(Continue reading)

Permalink | Reply | 1 comment |
headers
Josef Bacik | 1 Feb 2009 14:38
Picon
Favicon

Re: [PATCH] btrfs: Handle SGID bit when creating inodes

On Sat, Jan 31, 2009 at 10:48:54PM -0500, Chris Ball wrote:
> Before this patch, new files/dirs would ignore the SGID bit on their
> parent directory and always be owned by the creating user's uid/gid.
> 
> Signed-off-by: Chris Ball <cjb <at> laptop.org>

Looks good, thanks much for taking care of this,

Josef
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |
headers
Yoshihiro Takahashi | 2 Feb 2009 08:00
Favicon

Re: report, kernel BUG at fs/btrfs/extent-tree.c:3106

Hi, Josef

On Fri, 30 Jan 2009 08:49:35 -0500 Josef Bacik <jbacik <at> redhat.com> wrote:
> On Fri, Jan 30, 2009 at 02:35:28PM +0900, Yoshihiro Takahashi wrote:
> > Hi.
> > 
> > I create many files on btrfs of 16GB partition.
> > may 13,000,000 files.
> > I get this report.
> > 
> > I think about the following fix.
> > When there is not space, return of ENOSPC.
> > Or add lock in free extents.
> >
> 
> Are you just creating files, or are you doing something else?  Thanks,
> 
> Josef 
> --

I made a lot of files. 
Perhaps surpass 13,000,000 file. 

I created directry first.
I get this BUG when I made the file afterwards.

I got the following report to count of the files when I performed find.

Best regards,
Yoshihiro Takahashi
(Continue reading)

Permalink | Reply | 4 comments |
headers
Hisashi Hifumi | 2 Feb 2009 12:00
Picon

[PATCH] btrfs: call mark_inode_dirty when i_size is updated

Hi Chris.

I think it is needed to call mark_inode_dirty() when file size expands
in order to flush metadata updates to HDD through sync() syscall or
background_writeout().

Thanks.

Signed-off-by: Hisashi Hifumi <hifumi.hisashi <at> oss.ntt.co.jp>

diff -Nrup linux-2.6.29-rc3.org/fs/btrfs/file.c linux-2.6.29-rc3/fs/btrfs/file.c
--- linux-2.6.29-rc3.org/fs/btrfs/file.c	2009-02-02 16:53:18.000000000 +0900
+++ linux-2.6.29-rc3/fs/btrfs/file.c	2009-02-02 18:21:00.000000000 +0900
 <at>  <at>  -152,7 +152,7  <at>  <at>  static noinline int dirty_and_release_pa
 	}
 	if (end_pos > isize) {
 		i_size_write(inode, end_pos);
-		btrfs_update_inode(trans, root, inode);
+		mark_inode_dirty(inode);
 	}
 	err = btrfs_end_transaction(trans, root);
 out_unlock:

--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 5 comments |
headers
Chris Mason | 2 Feb 2009 15:12
Picon
Favicon

Re: [PATCH] btrfs: call mark_inode_dirty when i_size is updated

On Mon, 2009-02-02 at 20:00 +0900, Hisashi Hifumi wrote:
> Hi Chris.
> 
> I think it is needed to call mark_inode_dirty() when file size expands
> in order to flush metadata updates to HDD through sync() syscall or
> background_writeout().
> 

Thanks for reading through this code and sending the patch.

I find the I_DIRTY flags one of the more confusing parts of the generic
fs writeback cdoe.  But, I think what happens is the
btrfs_set_page_dirty function calls __set_page_dirty_nobuffers() which
does:

if (mapping->host) {
     /* !PageAnon && !swapper_space */
      __mark_inode_dirty(mapping->host, I_DIRTY_PAGES);
}

This should be enough to make sure the btrfs inodes are processed by
background writeout and sync().  Please let me know if I'm misreading
things.

-chris

--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
(Continue reading)

Permalink | Reply | 4 comments |
headers
Steven Pratt | 2 Feb 2009 16:58
Picon
Favicon

More performance results

Finally cleared out a backlog of results to upload.  Main performance 
page is updated with all the links.  (http://btrfs.boxacle.net/)  Most 
recent results are on 2.6.29-rc2. As usual see analysis directory of 
results for oprofile, including call graphs.

Single disk results are not too bad.  Raid still falls apart on any 
write heavy workload.

Steve

--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |
headers
Chris Mason | 2 Feb 2009 17:00
Picon
Favicon

Re: More performance results

On Mon, 2009-02-02 at 09:58 -0600, Steven Pratt wrote:
> Finally cleared out a backlog of results to upload.  Main performance 
> page is updated with all the links.  (http://btrfs.boxacle.net/)  Most 
> recent results are on 2.6.29-rc2. As usual see analysis directory of 
> results for oprofile, including call graphs.
> 
> Single disk results are not too bad.  Raid still falls apart on any 
> write heavy workload.

Thanks Steve, was the mainline btrfs used for this?  I'm working on the
write heavy problems this week.

-chris

--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 1 comment |
headers
Steven Pratt | 2 Feb 2009 18:35
Picon
Favicon

Re: More performance results

Chris Mason wrote:
> On Mon, 2009-02-02 at 09:58 -0600, Steven Pratt wrote:
>   
>> Finally cleared out a backlog of results to upload.  Main performance 
>> page is updated with all the links.  (http://btrfs.boxacle.net/)  Most 
>> recent results are on 2.6.29-rc2. As usual see analysis directory of 
>> results for oprofile, including call graphs.
>>
>> Single disk results are not too bad.  Raid still falls apart on any 
>> write heavy workload.
>>     
>
> Thanks Steve, was the mainline btrfs used for this?  I'm working on the
> write heavy problems this week.
>
>   
This was straight mainline Linus tree.

Steve

> -chris
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo <at> vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>   

--
(Continue reading)

Permalink | Reply | 0 comments |
headers
Diego Calleja | 2 Feb 2009 19:13
Picon

Re: btrfs-unstable tree updated to 2.6.29-rc3

El Thu, 29 Jan 2009 11:54:20 -0500, Chris Mason <chris.mason <at> oracle.com> escribió:

> The unstable tree hasn't been updated yet, I want to keep it compiling

You forgot to update the unstable-standalone tree (or its going to be
discontinued?)
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 1 comment |

Gmane