Re: [Gluster-devel] Using syncop_readdir inside Xlator

[Poornima Gurusiddaiah]

On Tue, Mar 27, 2018, 8:48 PM David Spisla  wrote:

> Dear Gluster Devels,
>
> I want to read all the entries in a DIR inside of a xlator. For this
> purpose I use the syncop_readdir function which is also used in die
> self-heal functionality for example.
> Here is a piece of code from inside the worm_rename function:
>
>
>fd_t *fd = NULL;
>gf_dirent_t   entries;
>
> fd = fd_anonymous (oldloc->inode);
> if (fd == NULL) {
> gf_log (this->name, GF_LOG_ERROR, "fd creation
> failed");
> ret = -ENOMEM;
> goto out;
> }
> INIT_LIST_HEAD ();
> ret = syncop_readdir (this, fd, 131072, 0, , NULL,
> NULL);
> if (ret) {
>

Readdir returns the number of entries read, hence ret will be > 0, if there
are dir entries read and it's a success case. The check should be ret < 0.
If it fails with ret < 0 case then I would suspect fd_anonymous, I m not
sure whether it works for readdir, need to check the code.

Regards,
Poornima

gf_log (this->name, GF_LOG_ERROR, "failed getting
> dir entries");
> ret = -ENOMEM;
> goto out;
>}
>
> The problem is, that I always get the Error: "failed getting dir entries"
> . It seems to be that there is something wrong with the execution of that
> function. Any ideas?
>
> Regards
> David Spisla
> ___
> Gluster-devel mailing list
> Gluster-devel@gluster.org
> http://lists.gluster.org/mailman/listinfo/gluster-devel
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] Request For Opinions: what to do about the synthetic statfvs "tweak"?

[Raghavendra Talur]

On Wed 21 Mar, 2018, 3:57 PM Csaba Henk,  wrote:

> Hi list,
>
> We have an ancient hack that fuse not
> just passes on the statvfs data it's getting
> from the storage, but tweaks it by setting
> f_bsize / f_frsize to values of its own
> preference. [1]
>
> The supposed advantage is that f_bsize
> serves as a hint to applications for the
> preferred io size. (And regarding f_frsize --
> in Linux it's a historical workaround for
> certain bugs in userspace[2] that f_bsize
> and f_frsize are being kept equal.)
>
> However, this has the side effect of
> getting slightly different values for total
> and used/free space of a volume when
> accessed through libgfapi and when through
> fuse -- because these values are multiples
> of f_frsize, and libgfapi uses the native f_frsize
> of the backend (typically 4k), while fuse provides
> its synthetic f_frsize (typically 128k). So the
> libfgapi provided sizes are more granular.
>
> OTOH, I couldn't find any program in
> standard Unix userspace where the
> implementation commonly used in GNU/Linux
> would rely on the f_bsize hint. It does not
> mean there is none -- and then there is of course
> the vast space of non-standard userland.
>
> Possibiliities are:
>
> 1) retire the whole tweak and just pass on
>what we get from storage [3]
>

I prefer the above. It makes libgfapi and fuse consistent.


2) keep the f_bsize tweak, but drop the
>of f_frsize == f_bsize legacy workaround
>and take f_frsize from storage
> 3) keep everything as is, and put up with the
>fs stat divergence between transports
> +1) make behaviors of 1) to 3) tunable --
>   but I would not like to go this way in
>   the spirit of KISS, unless absolutely a
>   demand
>
> Developers: do you know of any scenario where
> we benefit from the f_bsize tweak?
>
> Users:
> - do you have any application that relies on f_bsize
>   and benefits from its custom value?
> - do you have any legacy application/stack
>   where the f_frsize == f_bsize workaround is
>   still needed (but GlusterFS  / RHGS is being kept
>   up to date, so a change in this regard would hit
>   your setup)?
>
> Thanks for your thoughts!
>
> Regards,
> Csaba
>
> [1]:
> https://github.com/gluster/glusterfs/blob/v4.0.0/xlators/mount/fuse/src/fuse-bridge.c#L3177-L3189
> [2]: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=11406
> [3] practically this will also imply f_frsize == f_bsize, because
>  Linux filesystems usually adhere to this convention
>
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

[Gluster-devel] Release 4.1: Schedule, scope and review focus

[Shyam Ranganathan]

Hi,

As we have completed potential scope for 4.1 release (reflected here [1]
and also here [2]), it's time to talk about the schedule.

- Branching date (and hence feature exception date): Apr 16th
- Week of Apr 16th release notes updated for all features in the release
- RC0 tagging: Apr 23rd
- Week of Apr 23rd, upgrade and other testing
- RCNext: May 7th (if critical failures, or exception features arrive late)
- RCNext: May 21st
- Week of May 21st, final upgrade and testing
- GA readiness call out: May, 28th
- GA tagging: May, 30th
- +2-4 days release announcement

and, review focus. As in older releases, I am starring reviews that are
submitted against features, this should help if you are looking to help
accelerate feature commits for the release (IOW, this list is the watch
list for reviews). This can be found handy here [3].

So, branching is in about 4 weeks!

Thanks,
Shyam

[1] Issues marked against release 4.1:
https://github.com/gluster/glusterfs/milestone/5

[2] github project lane for 4.1:
https://github.com/gluster/glusterfs/projects/1#column-1075416

[3] Review focus dashboard:
https://review.gluster.org/#/q/starredby:srangana%2540redhat.com
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] [Gluster-Maintainers] Release 4.1: LTM release targeted for end of May

[Shyam Ranganathan]

On 03/26/2018 12:33 AM, Aravinda wrote:
>>> Also want to propose that,  we include a release
>>> of http://github.com/gluster/gluster-health-report with 4.1, and make
>>> the project more usable.
>> In the theme of including sub-projects that we want to highlight, what
>> else should we tag a release for or highlight with 4.1?
>>
>> @Aravinda, how do you envision releasing this with 4.1? IOW, what
>> interop tests and hence sanity can be ensured with 4.1 and how can we
>> tag a release that is sane against 4.1?
> 
> Some more changes required to make it work with Gluster 4.x, I will work
> on fixing those issues and test scripts.
> 
> I have not yet started with Packaging for Fedora/Ubuntu. As of now
> available as `pip install`. Let me know if that is fine with 4.1 release.

Aravinda, what issue in the gluster-health-report repo should I track
for closure?

Thanks,
Shyam
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] [Gluster-Maintainers] Release 4.1: LTM release targeted for end of May

[Shyam Ranganathan]

On 03/23/2018 09:18 AM, Niels de Vos wrote:
> On Fri, Mar 23, 2018 at 10:17:28AM +0530, Amar Tumballi wrote:
>> On Thu, Mar 22, 2018 at 11:34 PM, Shyam Ranganathan 
>> wrote:
>>
>>> On 03/21/2018 04:12 AM, Amar Tumballi wrote:
 Current 4.1 project release lane is empty! I cleaned it up, because I
 want to hear from all as to what content to add, than add things
>>> marked
 with the 4.1 milestone by default.


 I would like to see we have sane default values for most of the options,
 or have group options for many use-cases.
>>>
>>> Amar, do we have an issue that lists the use-cases and hence the default
>>> groups to be provided for the same?
>>>
>>>
>> Considering group options' task is more in glusterd2, the issue is @
>> https://github.com/gluster/glusterd2/issues/614 &
>> https://github.com/gluster/glusterd2/issues/454
> 
> Maybe somehow link those with
> https://github.com/gluster/glusterfs/issues/294 ?

All done. Updated the 4.1 release board with the GD2 issues and posted a
comment linking glusterfs issue with the same.
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

[Gluster-devel] Using syncop_readdir inside Xlator

[David Spisla]

Dear Gluster Devels,

I want to read all the entries in a DIR inside of a xlator. For this
purpose I use the syncop_readdir function which is also used in die
self-heal functionality for example.
Here is a piece of code from inside the worm_rename function:


   fd_t *fd = NULL;
   gf_dirent_t   entries;

fd = fd_anonymous (oldloc->inode);
if (fd == NULL) {
gf_log (this->name, GF_LOG_ERROR, "fd creation
failed");
ret = -ENOMEM;
goto out;
}
INIT_LIST_HEAD ();
ret = syncop_readdir (this, fd, 131072, 0, , NULL,
NULL);
if (ret) {
gf_log (this->name, GF_LOG_ERROR, "failed getting
dir entries");
ret = -ENOMEM;
goto out;
   }

The problem is, that I always get the Error: "failed getting dir entries" .
It seems to be that there is something wrong with the execution of that
function. Any ideas?

Regards
David Spisla
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

[Gluster-devel] Coverity covscan for 2018-03-27-ab8d1894 (master branch)

[staticanalysis]

GlusterFS Coverity covscan results are available from
http://download.gluster.org/pub/gluster/glusterfs/static-analysis/master/glusterfs-coverity/2018-03-27-ab8d1894
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel