xfs
[Top] [All Lists]

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

To: Dave Chinner <david@xxxxxxxxxxxxx>, xfs@xxxxxxxxxxx
Subject: Re: [PATCH 2/2] xfs_spaceman: Accounting for AGFL blocks
From: Dhruvesh Rathore <adrscube@xxxxxxxxx>
Date: Fri, 30 Jan 2015 13:55:30 +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=x2P0O5Qu4060LpF/LJ0NA1qQ7rxGtOdqQcS/k04wNdE=; b=0DGpNy3sjL13wrSbqPTKguIkCBdEMuWoGQpFFhyunoyVP8Gd+W0uu4i+oQjq0OeZI7 d0R9KZYbbNzbMoW8gtVrjj4UkfWyeIiuDLHc2GxNtUNPzO2kkaEcCxldkHgNbWGfYo7K 1ptMBkd7RbYEk02z/5ht+fNDvuZ0HJVFOL3ddxPymuOkDnRmj69t58Mj7lbeNULcwjAY ShTi+Iag5FEEuS1Vn+JksZuHxsLPrKUuIjNBivFAfqCopryrgqLJwMEvT0sdDF1lDNnL Q0nJ8L46qasj8H6jImr2E3uAHxaxnaWL/jD7qii1TujtZSukAN0hJGlfaXsrR7hbGO8O a1mA==
In-reply-to: <20150130013456.GA4251@dastard>
References: <54c1c12e.230a460a.4729.11fc@xxxxxxxxxxxxx> <20150128015757.GT16552@dastard> <CALJmpHP=vjz_ZY9sFpW8k2Y7TL+sz-WyjPeMoy4sM6XDTt8MTQ@xxxxxxxxxxxxxx> <20150128205956.GA6282@dastard> <CALJmpHOFVZer7YL8Kek6jk2U8f7JyBrJknYzVhyowht_EGm7DQ@xxxxxxxxxxxxxx> <20150130013456.GA4251@dastard>
On Fri, Jan 30, 2015 at 7:04 AM, Dave Chinner <david@xxxxxxxxxxxxx> wrote:
> [ please reply to the list! ]

We apologize it was an honest mistake.
We had hit reply instead of typing in the 'to field'.

>
> On Thu, Jan 29, 2015 at 09:18:03AM +0530, Dhruvesh Rathore 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.

> The range checking is not for validity of the blocks themselves -
> the ranges passed in come from the user. i.e. the user is asking for
> free space blocks within a certain range on disk. The blocks in the
> AGFL may or may not lie within that the user specified range, and so
> need to be checked against the range (similar to btree extents) to
> determine if they shoul dbe added to the FIEMAPFS output...
>

We have incorporated the above changes, and sent the updated patches on
the mailing list. Here are the links:

http://oss.sgi.com/archives/xfs/2015-01/msg00484.html
http://oss.sgi.com/archives/xfs/2015-01/msg00486.html
http://oss.sgi.com/archives/xfs/2015-01/msg00487.html
http://oss.sgi.com/archives/xfs/2015-01/msg00488.html
http://oss.sgi.com/archives/xfs/2015-01/msg00489.html

Regards,
A-DRS

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