Btrfs devel - Oct 2008 - Question about e8569813849b5da394a195c7e76b4faa452b12d1

Hello,

Is there a reason 

-       if (search_end == (u64)-1)
-               search_end = btrfs_super_total_bytes(&info->super_copy);

happened in the commit from $SUBJECT?  If its just a mistake thats fine
I''ll add
it back with my current patch, but if there is a reason it needed to go then I
need to know that too so I can figure out a different way to do what I want to
do.  Thanks,

Josef
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs"
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On Wed, 2008-10-08 at 16:59 -0400, Josef Bacik wrote:
> Hello,
> 
> Is there a reason 
> 
> -       if (search_end == (u64)-1)
> -               search_end =
btrfs_super_total_bytes(&info->super_copy);
> 
> happened in the commit from $SUBJECT?  If its just a mistake thats fine
I''ll add
> it back with my current patch, but if there is a reason it needed to go
then I
> need to know that too so I can figure out a different way to do what I want
to
> do.  Thanks,
Yan removed this as part of the prep code for space balancing.  It is
probably because he needs to change btrfs_super_total_bytes and we
can''t
rely on it as search_end anymore.

-chris


--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs"
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

2008/10/9 Josef Bacik <jbacik@redhat.com>:
> Hello,
>
> Is there a reason
>
> -       if (search_end == (u64)-1)
> -               search_end =
btrfs_super_total_bytes(&info->super_copy);
>
> happened in the commit from $SUBJECT?  If its just a mistake thats fine
I''ll add
> it back with my current patch, but if there is a reason it needed to go
then I
> need to know that too so I can figure out a different way to do what I want
to
> do.  Thanks,
>
btrfs_super_total_bytes is total size of all devices. we can''t rely on
it as
search_end for two reasons:

1) If metadata mirror is enable, the value can be larger than the last byte of
    last chunk.

2) For a FS has been balanced, there are some ''holes'' in the
chunk address
    space, so the value can be smaller than the last byte of last chunk.

Regards
Yan Zheng
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs"
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On Thu, Oct 09, 2008 at 09:47:41AM +0800, Yan Zheng
wrote:
> 2008/10/9 Josef Bacik <jbacik@redhat.com>:
> > Hello,
> >
> > Is there a reason
> >
> > -       if (search_end == (u64)-1)
> > -               search_end =
btrfs_super_total_bytes(&info->super_copy);
> >
> > happened in the commit from $SUBJECT?  If its just a mistake thats
fine I''ll add
> > it back with my current patch, but if there is a reason it needed to
go then I
> > need to know that too so I can figure out a different way to do what I
want to
> > do.  Thanks,
> >
> 
> btrfs_super_total_bytes is total size of all devices. we can''t
rely on it as
> search_end for two reasons:
> 
> 1) If metadata mirror is enable, the value can be larger than the last byte
of
>     last chunk.
> 
> 2) For a FS has been balanced, there are some ''holes'' in
the chunk address
>     space, so the value can be smaller than the last byte of last chunk.
>
Awesome thanks this is what I needed.  So here''s my next question,
we''re hitting
ENOSPC before we''re empty because of the way I currently lookup block
groups in
find_free_extent, so I''m rewriting find_free_extent to lookup the
btrfs_space_info that we are looking to allocate out of, and just loop through
its list of block groups, starting at the one that the hint points to, until we
find what we need.  This way I can incorporate find_free_space into
find_free_extent and make the code a little easier to read.  Will this upset
what you are trying to do with the space balancing code?  Thanks,

Josef 
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs"
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html