[Top] [All Lists]

Re: [PATCH 2/2] xfs_spaceman: Accounting for AGFL blocks

To: xfs@xxxxxxxxxxx, Dave Chinner <david@xxxxxxxxxxxxx>
Subject: Re: [PATCH 2/2] xfs_spaceman: Accounting for AGFL blocks
From: Dhruvesh Rathore <adrscube@xxxxxxxxx>
Date: Thu, 29 Jan 2015 18:28:16 +0530
Delivered-to: xfs@xxxxxxxxxxx
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=CCg/fQ8/cCtb67e1wi/lsS6mYmqKP/ONBN87TTD0/10=; b=EMkt4w5bM87oYbfrucGWeRBj0WaaSglp8TPprYIrbcuircGdSfgUpKXe/7u+0BgcNX DpDBjwg9J4YpQaQyxDTlPMI+AFvi2B0eSeSI/VdWDPR3E4KWdkkte3JJwp4vUJSbLoqb WoS8WnxT5mEw3NQNLqAVDv6wuRrxDfRvC56C0HW/8VWM53cpUnzk/14abCRoXBrlU613 XPuQP/SrBF18JNl/hQh7ode3lFPW2/8UpKM63VrkCSJ0rSPtRmq7yBbisrN+ryvig28X Y0W2TpAlnEdrNKS9T3h5u9WrcKsI3Rqv1jaBmNanN9wCJTtSWtMljnQnftrExVMhlxda KUXA==
In-reply-to: <CALJmpHNVSsdYp1pwfBjmhJHCnaXwrp071mwp20GfxaQynsYrNA@xxxxxxxxxxxxxx>
References: <54c1c12e.230a460a.4729.11fc@xxxxxxxxxxxxx> <20150128015757.GT16552@dastard> <CALJmpHP=vjz_ZY9sFpW8k2Y7TL+sz-WyjPeMoy4sM6XDTt8MTQ@xxxxxxxxxxxxxx> <20150128205956.GA6282@dastard> <CALJmpHOFVZer7YL8Kek6jk2U8f7JyBrJknYzVhyowht_EGm7DQ@xxxxxxxxxxxxxx> <CALJmpHNVSsdYp1pwfBjmhJHCnaXwrp071mwp20GfxaQynsYrNA@xxxxxxxxxxxxxx>
On Thu, Jan 29, 2015 at 9:18 AM, Dhruvesh Rathore <adrscube@xxxxxxxxx> wrote:
> On Thu, Jan 29, 2015 at 2:29 AM, Dave Chinner <david@xxxxxxxxxxxxx> wrote:
>> On Wed, Jan 28, 2015 at 06:35:22PM +0530, ADRS PICT wrote:
>>> On Wed, Jan 28, 2015 at 7:27 AM, Dave Chinner <david@xxxxxxxxxxxxx> wrote:
>>> > Hmmm - I think something is still missing - what are the sagbno and
>>> > eagbno parameters supposed to do?
>>> Actually the parameters sagbno and eagbno are not needed in this
>>> function and can be excluded.
>> Why? Don't we still have to check the blocks found on the AGFL fll
>> within the range requested by the user, like we do for every extent
>> found in the btree?
> We had felt that the range check is not needed as we are fetching block 
> numbers
> from the allocation group free block array by the function
> xfs_alloc_read_agfl().
> And in xfs_alloc_read_agfl(), the error checking is done implicitly.
> However, after you have raised this point, it is clear to us that performing a
> range check will be a good way to catch and display a warning if the blocks 
> are
> out of range.

We have assimilated the changes you pointed out and have sent the
updated patches
in a new thread.


<Prev in Thread] Current Thread [Next in Thread>