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
>> from the allocation group free block array by the function
>> 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
>> range check will be a good way to catch and display a warning if the blocks
>> 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: