From patchwork Sat Sep 12 08:08:43 2009 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Damien Guibouret X-Patchwork-Id: 33520 Return-Path: X-Original-To: patchwork-incoming@bilbo.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from ozlabs.org (ozlabs.org [203.10.76.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mx.ozlabs.org", Issuer "CA Cert Signing Authority" (verified OK)) by bilbo.ozlabs.org (Postfix) with ESMTPS id DD88BB7B61 for ; Sat, 12 Sep 2009 18:06:33 +1000 (EST) Received: by ozlabs.org (Postfix) id CCDBADDDA2; Sat, 12 Sep 2009 18:06:33 +1000 (EST) Delivered-To: patchwork-incoming@ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.176.167]) by ozlabs.org (Postfix) with ESMTP id 74AAFDDD0C for ; Sat, 12 Sep 2009 18:06:33 +1000 (EST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751927AbZILIGY (ORCPT ); Sat, 12 Sep 2009 04:06:24 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751939AbZILIGY (ORCPT ); Sat, 12 Sep 2009 04:06:24 -0400 Received: from smtp2-g21.free.fr ([212.27.42.2]:58919 "EHLO smtp2-g21.free.fr" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751927AbZILIGW (ORCPT ); Sat, 12 Sep 2009 04:06:22 -0400 Received: from smtp2-g21.free.fr (localhost [127.0.0.1]) by smtp2-g21.free.fr (Postfix) with ESMTP id EDF514B0192 for ; Sat, 12 Sep 2009 10:06:19 +0200 (CEST) Received: from [192.168.103.118] (lan31-6-82-230-26-21.fbx.proxad.net [82.230.26.21]) by smtp2-g21.free.fr (Postfix) with ESMTP id 049DB4B00C4 for ; Sat, 12 Sep 2009 10:06:16 +0200 (CEST) Message-ID: <4AAB570B.70607@partition-saving.com> Date: Sat, 12 Sep 2009 10:08:43 +0200 From: Damien Guibouret User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050416 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-ext4@vger.kernel.org Subject: Re: flex_bg information initialization and question on resize/bad inodes with 48 bits filesystem References: <4AAA8F6C.6030206@partition-saving.com> <20090911183540.GB28764@mit.edu> In-Reply-To: <20090911183540.GB28764@mit.edu> Sender: linux-ext4-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org Theodore Tso wrote: > On Fri, Sep 11, 2009 at 07:57:00PM +0200, Damien Guibouret wrote: > >>I have looked at the new features provided by ext4 and have a question >>on flex_bg information initialization: >>into ext4_fill_flex_info function of fs/ext4/super.c (lines 1698, 1700 >>and 1702 for kernel 2.6.31) doesn't the atomic_set calls be atomic_add >>to sum statistics of each group composing a flex group, or do I >>misunderstand something ? > > > Good eye; that's a bug; thanks for pointing that out. > > >>For the extension to manage 48 bits blocks number, I do not see anything >>to treat this for resize and bad inodes into kernel or e2fsprogs. For >>the resize inode, it is perhaps an incompatibility of this feature with >>48 bits blocks number, but for the bad inode ? > > > There is a plan for how to handle online resizing for > 2^32 block > filesystems, but it hasn't been implemented yet. The basic support > for it is there; that's what the META_BG feature is designed to > support, so existing kernels will be able to deal with resized large > filesystemes. But the code to actually do the on-line resizing hasn't > been implemented yet. > > For the bad block inode, the solution is to make it be extent mapped > inode. This also hasn't been implemented yet, but this is a much > simpler one to write. The main reason why we haven't is that modern > disks rarely have system-visible bad blocks; normally the hard drive > has its own bad block remapping layer in hardware so we never see a > bad block until the disk is failing so badly it needs to be replaced > ASAP. > > - Ted > > Hi, Thanks for the information. Looking at ext4.h, I think the setting of extra time fields forgets to mask the epoch bits so the epoch part overwrites nsec part. The second change is only for coherency (2 -> EXT4_EPOCH_BITS): Regards, Damien --- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html --- fs/ext4/ext4.h.old 2009-09-12 09:45:42.161490080 +0200 +++ fs/ext4/ext4.h 2009-09-12 09:47:43.808996848 +0200 @@ -481,8 +481,8 @@ static inline __le32 ext4_encode_extra_time(struct timespec *time) { return cpu_to_le32((sizeof(time->tv_sec) > 4 ? - time->tv_sec >> 32 : 0) | - ((time->tv_nsec << 2) & EXT4_NSEC_MASK)); + (time->tv_sec >> 32) & EXT4_EPOCH_MASK : 0) | + ((time->tv_nsec << EXT4_EPOCH_BITS) & EXT4_NSEC_MASK)); } static inline void ext4_decode_extra_time(struct timespec *time, __le32 extra) @@ -490,7 +490,7 @@ if (sizeof(time->tv_sec) > 4) time->tv_sec |= (__u64)(le32_to_cpu(extra) & EXT4_EPOCH_MASK) << 32; - time->tv_nsec = (le32_to_cpu(extra) & EXT4_NSEC_MASK) >> 2; + time->tv_nsec = (le32_to_cpu(extra) & EXT4_NSEC_MASK) >> EXT4_EPOCH_BITS; } #define EXT4_INODE_SET_XTIME(xtime, inode, raw_inode) \