From mboxrd@z Thu Jan  1 00:00:00 1970
From: Boaz Harrosh <bharrosh@panasas.com>
Subject: Re: [RFC] vfs/inode: For none-block-based filesystems default to
 sb->s_bdi
Date: Tue, 05 Oct 2010 09:53:41 -0400
Message-ID: <4CAB2DE5.90801@panasas.com>
References: <4CAA4B1D.1010904@panasas.com> <4CAA4EE5.2070308@panasas.com> <20101005083208.GA3514@quack.suse.cz>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: Christoph Hellwig <hch@infradead.org>,
	Al Viro <viro@ZenIV.linux.org.uk>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	Trond Myklebust <Trond.Myklebust@netapp.com>,
	Benny Halevy <bhalevy@panasas.com>
To: Jan Kara <jack@suse.cz>
Return-path: <linux-fsdevel-owner@vger.kernel.org>
Received: from daytona.panasas.com ([67.152.220.89]:27885 "EHLO
	daytona.int.panasas.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org
	with ESMTP id S1753193Ab0JENxn (ORCPT
	<rfc822;linux-fsdevel@vger.kernel.org>);
	Tue, 5 Oct 2010 09:53:43 -0400
In-Reply-To: <20101005083208.GA3514@quack.suse.cz>
Sender: linux-fsdevel-owner@vger.kernel.org
List-ID: <linux-fsdevel.vger.kernel.org>

On 10/05/2010 04:32 AM, Jan Kara wrote:
>   Hi Boaz,
> 
> On Mon 04-10-10 18:02:13, Boaz Harrosh wrote:
>> Sorry I've just seen Jan's patch:
>> From: Jan Kara <jack@suse.cz>
>> Date: Mon, 27 Sep 2010 23:56:48 +0200
>> Subject: [PATCH] bdi: Initialize inode->i_mapping.backing_dev_info to sb->s_bdi
> ...
>> That works for me as well. Was it decided how to solve this? Other wise
>> I'll need to patch exofs, ASAP for this -rc
>   In the end, we'll use Christoph's patch
> (http://lkml.org/lkml/2010/9/29/76) changing inode_to_bdi() to be
> more conservative and also the warning will be gone. So you don't have to
> patch anything...
> 
> 								Honza

I would still like to fix it. Currently each inode->mapping.backing_dev_info in my
none-block-filesystem is set to &default_backing_dev_info. This sounds scary!
what about the future patches that will schedule a wakup on set_inode_dirty ?
Will they not need my proper sb->s_bdi on each ->mapping?

I could do it in the filesystem, but the way the code is now I'll need to
set it in 5 different places, or clean up the code with more common code.

That said, I think your (or my) patch makes much more sense. The sb->s_bdi
is a much better common default then &default_backing_dev_info. By now
is &default_backing_dev_info really needed at all?

I guess I'll have to go head and do it in FS code.

Thanks
Boaz