From mboxrd@z Thu Jan 1 00:00:00 1970 From: Boaz Harrosh Subject: Re: Problem found, but why??? Date: Wed, 02 Feb 2011 20:46:52 +0200 Message-ID: <4D49A69C.4040801@panasas.com> References: <4D498ADC.4060306@panasas.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit To: linux-fsdevel , Al Viro , Andrew Morton , Nick Piggin Return-path: Received: from daytona.panasas.com ([67.152.220.89]:36745 "EHLO daytona.panasas.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754657Ab1BBSq5 (ORCPT ); Wed, 2 Feb 2011 13:46:57 -0500 In-Reply-To: <4D498ADC.4060306@panasas.com> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: 115e19c53501edc11f730191f7f047736815ae3d is the first bad commit commit 115e19c53501edc11f730191f7f047736815ae3d Author: Boaz Harrosh exofs: Set i_mapping->backing_dev_info anyway OK It's stupid ME. But why please someone explain this issue? For now I'll send a revert, but I would like this explained, perhaps a more solid fix is needed. Please look at this patch: diff --git a/fs/exofs/inode.c b/fs/exofs/inode.c index 24ab327..0ba9886 100644 --- a/fs/exofs/inode.c +++ b/fs/exofs/inode.c @@ -1030,6 +1030,7 @@ struct inode *exofs_iget(struct super_block *sb, unsigned long ino) memcpy(oi->i_data, fcb.i_data, sizeof(fcb.i_data)); } + inode->i_mapping->backing_dev_info = sb->s_bdi; if (S_ISREG(inode->i_mode)) { inode->i_op = &exofs_file_inode_operations; inode->i_fop = &exofs_file_operations; @@ -1129,6 +1130,7 @@ struct inode *exofs_new_inode(struct inode *dir, int mode) sbi = sb->s_fs_info; + inode->i_mapping->backing_dev_info = sb->s_bdi; sb->s_dirt = 1; inode_init_owner(inode, dir, mode); inode->i_ino = sbi->s_nextid++; All it does is set the inode's bdi to point to the super-block bdi. In stead of this default "null" bdi from VFS. When we do so the read-ahead stops coming, completely. Is there something that needs to be implemented farther for a super-block's bdi to support read-ahead? Please help? Thanks Boaz