From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Perepechko Subject: Re: [RFC] quota: 64-bit limits with vfs, updated Date: Fri, 21 Mar 2008 12:14:12 +0300 Message-ID: <200803211214.12905.andrew.perepechko@sun.com> References: <200803061641.12274.andrew.perepechko@sun.com> <200803210037.38094.andrew.perepechko@sun.com> <20080321010403.GA2971@webber.adilger.int> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT Cc: Jan Kara , Johann Lombardi , Zhiyong Landen tian , Alex Lyashkov To: linux-fsdevel@vger.kernel.org Return-path: Received: from brmea-mail-2.Sun.COM ([192.18.98.43]:33447 "EHLO brmea-mail-2.sun.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752676AbYCUJLJ (ORCPT ); Fri, 21 Mar 2008 05:11:09 -0400 Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m2L9B84d027851 for ; Fri, 21 Mar 2008 09:11:08 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JY200I01PC0X900@mail-amer.sun.com> (original mail from Andrew.Perepechko@Sun.COM) for linux-fsdevel@vger.kernel.org; Fri, 21 Mar 2008 03:11:08 -0600 (MDT) In-reply-to: <20080321010403.GA2971@webber.adilger.int> Content-disposition: inline Sender: linux-fsdevel-owner@vger.kernel.org List-ID: Hello, Andreas. On Friday 21 March 2008 04:04:03 you wrote: > On Mar 21, 2008 00:37 +0300, Andrew Perepechko wrote: > > +#define REV_ASSERT(r) BUG_ON((rev) != 0 && (rev) != 1) > > Umm, "r" and "rev" are not consistent above... > Indeed. In the beginning I made this macro without arguments, then added this argument not too carefully. It should work anyway since it depends on rev, not r, but this needs to be fixed to make sense. > Since this assertion is only on the in-memory quota structure, it would > probably be better to have something like > > #define REV_R0 0x12340000 > #define REV_R1 0x12340001 > > and when unpacking the on-disk revision number or it with REV_OFFSET and > > #define REV_ASSERT(revno) BUG_ON((revno) != REV_R0 && (revno) != REV_R1) > > That detects the common case of memory being zeroed for some reason. It > will also easily detect if you aren't properly swabbing the revision > and unmasking the 0x1234000 from the in-memory structure. I think it is a good idea. We can't do a lot for swabbing checks since 0 is for old revision (and we can't change this) and 1 is a good enough swabbing check. But for internal consistency purposes in-memory 0x12340000 and 0x12340001 values look better than 0 and 1. > > Just a thought... some people may not like this idea, but I dislike > using "0" as a magic number for anything. > > Cheers, Andreas > -- > Andreas Dilger > Sr. Staff Engineer, Lustre Group > Sun Microsystems of Canada, Inc. > > Best. Andrew.