Alexandre Oliva
2011-Oct-29 04:35 UTC
Re: Patches for BTRFS (mail-server slow down in 3.0 and more)
On Oct 28, 2011, Marcel Lohmann <marcel@malowa.de> wrote:> I would really appreciate if you could send me the patches.Here are the patches I mentioned on IRC. I''ve sent two of them to Josef for him to push upstream, but I''m not sure he posted them here for I''m not on the list (yet?). The other two are newer, and the last one is definitely not for inclusion (just for testing or as a temporary work-around). I''ve been using the first 3 with some success on a couple of mail servers: I haven''t hit the ridiculous slow downs from frequent unsuccessful calls of setup_cluster_no_bitmap after a while, like I did with 3.0 (and 3.1) any more. However, the excess use of metadata that I''ve experienced on ceph OSDs isn''t fixed by them. A btrfs balance with the first 3 still has 22GB of metadata block groups even though only 4.1GB of metadata are in use, or 19GB of metadata with only 2GB of metadata in use. With the 4th patch and -o clear_cache, the first rebalancing of the 22GB-metadata filesystem got it down to 8GB; the second fs is still on rebalancing ~800GB (wishlist mental note: introduce some means to rebalance only the metadata) Here are the patches, against 3.1-libre (should apply cleanly on 3.1). -- Alexandre Oliva, freedom fighter http://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist Red Hat Brazil Compiler Engineer
Chris Mason
2011-Oct-29 05:12 UTC
Re: Patches for BTRFS (mail-server slow down in 3.0 and more)
On Sat, Oct 29, 2011 at 02:35:16AM -0200, Alexandre Oliva wrote:> On Oct 28, 2011, Marcel Lohmann <marcel@malowa.de> wrote: > > > I would really appreciate if you could send me the patches. > > Here are the patches I mentioned on IRC. I''ve sent two of them to Josef > for him to push upstream, but I''m not sure he posted them here for I''m > not on the list (yet?). The other two are newer, and the last one is > definitely not for inclusion (just for testing or as a temporary > work-around).The last one isn''t a bad idea, but please do make a real mount option for it ;) -chris -- 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
Alexandre Oliva
2011-Oct-31 04:19 UTC
Re: Patches for BTRFS (mail-server slow down in 3.0 and more)
On Oct 29, 2011, Chris Mason <chris.mason@oracle.com> wrote:> The last one isn''t a bad idea, but please do make a real mount option > for it ;)Like this? -- Alexandre Oliva, freedom fighter http://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist Red Hat Brazil Compiler Engineer
David Sterba
2011-Oct-31 14:30 UTC
Re: Patches for BTRFS (mail-server slow down in 3.0 and more)
On Mon, Oct 31, 2011 at 02:19:18AM -0200, Alexandre Oliva wrote:> On Oct 29, 2011, Chris Mason <chris.mason@oracle.com> wrote: > > > The last one isn''t a bad idea, but please do make a real mount option > > for it ;) > > Like this?@@ -195,6 +195,7 @@ static match_table_t tokens = { {Opt_subvolrootid, "subvolrootid=%d"}, {Opt_defrag, "autodefrag"}, {Opt_inode_cache, "inode_cache"}, + {Opt_nocluster, "nocluster"}, {Opt_err, NULL}, How about ''no_alloc_cluster'' ? Or something suggesting it''s related to allocation. At least we''re not in situation of ocfs2 where are clusters in block-gouping- but also host-grouping sense, so I''m fine with nocluster. Just in case somebody has a better idea for the option name. david -- 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
Alexandre Oliva
2011-Oct-31 18:08 UTC
Re: Patches for BTRFS (mail-server slow down in 3.0 and more)
On Oct 31, 2011, David Sterba <dave@jikos.cz> wrote:> On Mon, Oct 31, 2011 at 02:19:18AM -0200, Alexandre Oliva wrote: >> On Oct 29, 2011, Chris Mason <chris.mason@oracle.com> wrote: >> >> > The last one isn''t a bad idea, but please do make a real mount option >> > for it ;) >> >> Like this?> @@ -195,6 +195,7 @@ static match_table_t tokens = { > {Opt_subvolrootid, "subvolrootid=%d"}, > {Opt_defrag, "autodefrag"}, > {Opt_inode_cache, "inode_cache"}, > + {Opt_nocluster, "nocluster"}, > {Opt_err, NULL},> How about ''no_alloc_cluster'' ?I considered that, too, but choosing the option name was the most difficult part of the patch :-) I ended up going for the shorter name, just to get the conversation started ;-) I don''t feel strongly about it. -- Alexandre Oliva, freedom fighter http://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist Red Hat Brazil Compiler Engineer -- 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