headers
Jan Engelhardt | 1 Jun 2008 21:04
Picon

btrfs-bdi.patch


This one has not been applied for btrfs 0.15 yet.

---
 btrfs/disk-io.c |    6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

Index: btrfs-0.14/btrfs/disk-io.c
===================================================================
--- btrfs-0.14.orig/btrfs/disk-io.c
+++ btrfs-0.14/btrfs/disk-io.c
 <at>  <at>  -968,7 +968,7  <at>  <at>  void btrfs_unplug_io_fn(struct backing_d

 static int setup_bdi(struct btrfs_fs_info *info, struct backing_dev_info *bdi)
 {
-#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,23)
+#if LINUX_VERSION_CODE > KERNEL_VERSION(2,6,23)
 	bdi_init(bdi);
 #endif
 	bdi->ra_pages	= default_backing_dev_info.ra_pages;
 <at>  <at>  -1349,7 +1349,7  <at>  <at>  fail:

 	kfree(extent_root);
 	kfree(tree_root);
-#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,23)
+#if LINUX_VERSION_CODE > KERNEL_VERSION(2,6,23)
 	bdi_destroy(&fs_info->bdi);
 #endif
 	kfree(fs_info);
 <at>  <at>  -1608,7 +1608,7  <at>  <at>  int close_ctree(struct btrfs_root *root)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jan Engelhardt | 1 Jun 2008 21:05
Picon

[patch] resolve compile error on -rt


Required to make it compiled with -rt patchset.

---
 btrfs/inode.c |    1 -
 1 file changed, 1 deletion(-)

Index: btrfs-0.14/inode.c
===================================================================
--- btrfs-0.14.orig/btrfs/inode.c
+++ btrfs-0.14/btrfs/inode.c
 <at>  <at>  -3139,7 +3139,6  <at>  <at>  struct inode *btrfs_alloc_inode(struct s
 void btrfs_destroy_inode(struct inode *inode)
 {
 	WARN_ON(!list_empty(&inode->i_dentry));
-	WARN_ON(inode->i_data.nrpages);

 	btrfs_drop_extent_cache(inode, 0, (u64)-1);
 	kmem_cache_free(btrfs_inode_cachep, BTRFS_I(inode));
--
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
Chris Mason | 1 Jun 2008 21:23
Picon
Favicon

Re: [patch] resolve compile error on -rt

On Sunday 01 June 2008, Jan Engelhardt wrote:
> Required to make it compiled with -rt patchset.

I thought -rt had the rcu page cache patches as well.  Btrfs should need 
larger changes for that.

Thanks for the bdi patch, I'll queue that up.

-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 | 0 comments |
headers
Ric Wheeler | 2 Jun 2008 19:52
Picon
Favicon

btrfs panic - BUG: soft lockup - CPU#0 stuck for 61s! [fs_mark:4573]


I can reliably get btrfs to panic by running my fs_mark code on a newly 
created file system with lots of threads on an 8-way box. If this is too 
aggressive, let me know ;-)

Here is a summary of the panic:

EXT3-fs: recovery complete.
EXT3-fs: mounted filesystem with ordered data mode.
device fsid 814e6131acbfcbec-7a2a40df880929bb devid 1 transid 495 /dev/sdb1
BUG: soft lockup - CPU#1 stuck for 61s! [fs_mark:4572]
CPU 1:
Modules linked in: btrfs libcrc32c ipt_MASQUERADE iptable_nat nf_nat 
bridge bnep rfcomm l2cap bluetooth ib_iser rdma_cm ib_cm iw_cm ib_sa 
ib_mad ib_core ib_addr iscsi_tcp libiscsi scsi_transport_iscsi fuse 
sunrpc ipt_REJECT nf_conntrack_ipv4 iptable_filter ip_tables ip6t_REJECT 
xt_tcpudp nf_conntrack_ipv6 xt_state nf_conntrack ip6table_filter 
ip6_tables x_tables ipv6 dm_mirror dm_multipath dm_mod kvm_intel kvm 
snd_hda_intel snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq 
snd_seq_device snd_pcm_oss iTCO_wdt snd_mixer_oss iTCO_vendor_support 
nvidia(P) pata_acpi button ata_piix snd_pcm ppdev firewire_ohci i2c_i801 
ata_generic firewire_core pcspkr dcdbas snd_timer sr_mod cdrom 
snd_page_alloc snd_hwdep snd tg3 serio_raw i2c_core shpchp crc_itu_t sg 
parport_pc soundcore parport floppy ahci libata sd_mod scsi_mod ext3 jbd 
mbcache uhci_hcd ohci_hcd ehci_hcd [last unloaded: freq_table]
Pid: 4572, comm: fs_mark Tainted: P         2.6.25.3-18.fc9.x86_64 #1
RIP: 0010:[<ffffffff81132929>]  [<ffffffff81132929>] 
__write_lock_failed+0x9/0x20
RSP: 0018:ffff81000c529e60  EFLAGS: 00000206
RAX: ffff810015c0e000 RBX: ffff81000c529e68 RCX: 0000000000000016
(Continue reading)

Permalink | Reply | 5 comments |
headers
Thomas King | 2 Jun 2008 23:46

Future Linux filesystems

Folks,

I am writing an article for Linux.com to answer Henry Newman's article at
http://www.enterprisestorageforum.com/sans/features/article.php/3749926
concerning Linux and massive filesystems. Is there someone here that can field
some questions about BTRFS?

Thanks!
Tom King
--
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
Joe Peterson | 3 Jun 2008 01:42
Picon
Favicon

'cp -p' leaves mode on destination files/dirs incorrect

Hi all, this is a problem observed in btrfs-0.15:

Using 'cp -p', 'cp -a', or moving files to btrfs from another filesystem
(which does a copy then remove) will leave the copied files with the
wrong mode.  Specifically, all permissions for 'group' or 'other' are
nulled out.  My umask is the typical 0022, but umask should not matter
here anyway (to make sure I wasn't crazy, I tried it on an ext3 partition).

The simplest example is:

touch bar
cp -p bar foo

Doing 'ls -l bar foo' yields:

-rw-r--r-- 1 joe skyrush 0 Jun  2 17:38 bar
-rw------- 1 joe skyrush 0 Jun  2 17:38 foo

For directories, if they used to have mode 755, the copies will then
have mode 700.

I first noticed this when moving dirs from another partition, but
'cp -a', of course, demonstrated it as well.

I do not know the btrfs code well yet, but I am willing to help
investigate this, especially of someone points me to the right place to
start looking.  :)

						-Thanks, Joe
--
(Continue reading)

Permalink | Reply | 1 comment |
headers
Yan Zheng | 3 Jun 2008 12:20
Favicon

Re: 'cp -p' leaves mode on destination files/dirs incorrect

2008/6/3 Joe Peterson <lavajoe <at> gentoo.org>:
> Hi all, this is a problem observed in btrfs-0.15:
>
> Using 'cp -p', 'cp -a', or moving files to btrfs from another filesystem
> (which does a copy then remove) will leave the copied files with the
> wrong mode.  Specifically, all permissions for 'group' or 'other' are
> nulled out.  My umask is the typical 0022, but umask should not matter
> here anyway (to make sure I wasn't crazy, I tried it on an ext3 partition).

Hello,

This is a known bug.  The attached patch can temporarily fix it.

Regards
YZ
---
diff -r 4b7e2b315a32 xattr.c
--- a/xattr.c	Thu May 29 10:31:43 2008 -0400
+++ b/xattr.c	Tue Jun 03 18:19:19 2008 +0800
 <at>  <at>  -29,22 +29,22  <at>  <at>  static struct xattr_handler *btrfs_xattr
 static struct xattr_handler *btrfs_xattr_handler_map[] = {
 	[BTRFS_XATTR_INDEX_USER]		= &btrfs_xattr_user_handler,
 #ifdef CONFIG_FS_POSIX_ACL
-	[BTRFS_XATTR_INDEX_POSIX_ACL_ACCESS]	= &btrfs_xattr_acl_access_handler,
-	[BTRFS_XATTR_INDEX_POSIX_ACL_DEFAULT]	= &btrfs_xattr_acl_default_handler,
+//	[BTRFS_XATTR_INDEX_POSIX_ACL_ACCESS]	= &btrfs_xattr_acl_access_handler,
+//	[BTRFS_XATTR_INDEX_POSIX_ACL_DEFAULT]	= &btrfs_xattr_acl_default_handler,
 #endif
 	[BTRFS_XATTR_INDEX_TRUSTED]		= &btrfs_xattr_trusted_handler,
 	[BTRFS_XATTR_INDEX_SECURITY]		= &btrfs_xattr_security_handler,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Thomas King | 3 Jun 2008 16:37

Re: Future Linux filesystems

> All the issues he complains about actually are solved by XFS, and XFS actually
does better in
> exactly these environments than either zfs on Solaris or JFS2 on AIX.
>
>

I asked the author that question and he states XFS is actually a pretty good
answer to most of those issues but believes it still falls short where "the
metadata areas are not aligned with RAID strips and allocation units are FAR too
small but better than ext." Another detail he brought out was sending data and
metadata to different devices in those environments and referenced RT XFS.
Otherwise having them on the same device increases the possibility of corruption
and/or a longer filesystem check/repair. Will btrfs offer something like this in
the future?

Do y'all foresee btrfs being used in exabtye installations?
Does/Will btrfs have RAID awareness in that it will align "the
superblock and metadata to the RAID stripe"?
What is the largest block allocation available?
Will btrfs be T10 DIF/block protect aware?
I remember reading that CRFS relies on btrfs, but will btrfs support NFS,
specifically version 4.1?

Thanks!
Tom King

--
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 | 8 comments |
headers
Joe Peterson | 3 Jun 2008 17:02
Picon
Favicon

Re: Future Linux filesystems

Thomas King wrote:
>> All the issues he complains about actually are solved by XFS, and XFS actually
> does better in
>> exactly these environments than either zfs on Solaris or JFS2 on AIX.
>>
>>
> 
> I asked the author that question and he states XFS is actually a pretty good
> answer to most of those issues but believes it still falls short where "the
> metadata areas are not aligned with RAID strips and allocation units are FAR too
> small but better than ext." Another detail he brought out was sending data and
> metadata to different devices in those environments and referenced RT XFS.
> Otherwise having them on the same device increases the possibility of corruption
> and/or a longer filesystem check/repair. Will btrfs offer something like this in
> the future?
> 
> Do y'all foresee btrfs being used in exabtye installations?
> Does/Will btrfs have RAID awareness in that it will align "the
> superblock and metadata to the RAID stripe"?
> What is the largest block allocation available?
> Will btrfs be T10 DIF/block protect aware?
> I remember reading that CRFS relies on btrfs, but will btrfs support NFS,
> specifically version 4.1?

You don't mention what I believe is the *key* issue (and I don't think
the author did either, but I skimmed his article): data integrity.  I'm
not talking about blatant failures or known need for an fsck, but rather
silent corruption.

Where I work, we are considering multi-petabyte scenarios, and with the
(Continue reading)

Permalink | Reply | 2 comments |
headers
Evgeniy Polyakov | 3 Jun 2008 17:52
Picon
Picon

Re: Future Linux filesystems

Hi.

On Tue, Jun 03, 2008 at 09:37:27AM -0500, Thomas King (kingttx <at> tomslinux.homelinux.org) wrote:
> I asked the author that question and he states XFS is actually a pretty good
> answer to most of those issues but believes it still falls short where "the
> metadata areas are not aligned with RAID strips and allocation units are FAR too
> small but better than ext." Another detail he brought out was sending data and
> metadata to different devices in those environments and referenced RT XFS.
> Otherwise having them on the same device increases the possibility of corruption
> and/or a longer filesystem check/repair. Will btrfs offer something like this in
> the future?

Right now btrfs can be created on top of multiple devices.
AFAIK, there are no policies on hwo to put data and metadata between them.

> Do y'all foresee btrfs being used in exabtye installations?
> Does/Will btrfs have RAID awareness in that it will align "the
> superblock and metadata to the RAID stripe"?
> What is the largest block allocation available?
> Will btrfs be T10 DIF/block protect aware?
> I remember reading that CRFS relies on btrfs, but will btrfs support NFS,
> specifically version 4.1?

Original author does not belive in networked filesystem as a key method
to organize large storages :)
Changes to filesystem are quite simple in order fs would be exported via
NFS, so that should not be a problem.

--

-- 
	Evgeniy Polyakov
(Continue reading)

Permalink | Reply | 1 comment |

Gmane