Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751440Ab0GMEqz (ORCPT ); Tue, 13 Jul 2010 00:46:55 -0400 Received: from idcmail-mo2no.shaw.ca ([64.59.134.9]:42214 "EHLO idcmail-mo2no.shaw.ca" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750747Ab0GMEqy convert rfc822-to-8bit (ORCPT ); Tue, 13 Jul 2010 00:46:54 -0400 X-Cloudmark-SP-Filtered: true X-Cloudmark-SP-Result: v=1.0 c=1 a=QI05LW3Htw8A:10 a=yQWWgrYGNuUA:10 a=VphdPIyG4kEA:10 a=kj9zAlcOel0A:10 a=c23vf5CSMVc0QQz9B4a6RA==:17 a=pQQoM67POyd5uB6soKAA:9 a=a3Znw9EKSIoXF2OAfrvfjT1ErZUA:4 a=CjuIK1q_8ugA:10 Subject: Re: [PATCH 2/2] OCFS2: Allow huge (> 16 TiB) volumes to mount Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Andreas Dilger In-Reply-To: Date: Mon, 12 Jul 2010 22:46:50 -0600 Cc: ocfs2-devel@oss.oracle.com, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-ext4@vger.kernel.org Content-Transfer-Encoding: 8BIT Message-Id: References: <871vbax86w.fsf@patl.com> <87zkxyvtjt.fsf@patl.com> <3BB069D5-B193-43A4-B678-B3CEA4873B58@dilger.ca> To: "Patrick J. LoPresti" X-Mailer: Apple Mail (2.1078) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1912 Lines: 37 On 2010-07-12, at 19:08, Patrick J. LoPresti wrote: > On Mon, Jul 12, 2010 at 5:21 PM, Andreas Dilger wrote: >> On 2010-07-11, at 11:04, Patrick J. LoPresti wrote: >>> >>> + /* Absolute addressability check (borrowed from ext4/super.c) */ >>> + if ((max_block > >>> + (sector_t)(~0LL) >> (osb->sb->s_blocksize_bits - 9)) || >>> + (max_block > (pgoff_t)(~0LL) >> (PAGE_CACHE_SHIFT - >>> + osb->sb->s_blocksize_bits))) { >>> + mlog(ML_ERROR, "Volume too large " >>> + "to mount safely on this system"); >>> + status = -EFBIG; >>> + goto out; >>> + } >> >> This hunk of code is actually in several filesystems. It wouldn't be a bad idea to make it a library function that can be called by the filesystem to check the kernel page cache and block layer can handle these large filesystems. > > True, but some of them do it differently (e.g. see the #if switch in > xfs_sb_validate_fsb_count). Tracking down all variants and changing > them is a much larger task than my simple patch. > > Are you suggesting I need to do this before my patch is accepted at > all? Or is this a refactoring that can happen later? I'm just suggesting it should be done at some point. I thought it would be better to do it first, rather than add yet another copy of this code. That said, I hate to block useful fixes because of cleanup (and I have no control over OCFS2 anyway :-). However, I've found that once the fix is in people usually forget (or become too busy) to do the cleanup and it just lingers on unseen. Cheers, Andreas -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/