Re: [Gluster-devel] How commonly applications make use of fadvise?

[Raghavendra G]

On Fri, Aug 11, 2017 at 5:50 PM, Ravishankar N 
wrote:

>
>
> On 08/11/2017 04:51 PM, Niels de Vos wrote:
>
>> On Fri, Aug 11, 2017 at 12:47:47AM -0400, Raghavendra Gowdappa wrote:
>>
>>> Hi all,
>>>
>>> In a conversation between me, Milind and Csaba, Milind pointed out
>>> fadvise(2) [1] and its potential benefits to Glusterfs' caching
>>> translators like read-ahead etc. After discussing about it, we agreed
>>> that our performance translators can leverage the hints to provide
>>> better performance. Now the question is how commonly applications
>>> actually provide hints? Is it something that is used quite frequently?
>>> If yes, we can think of implementing this in glusterfs (probably
>>> kernel-fuse too?). If no, there is not much of an advantage in
>>> spending our energies here. Your inputs will help us to prioritize
>>> this feature.
>>>
>> If functionality like this is available, we would add support in
>> libgfapi.so as well. NFS-Ganesha is prepared for consuming this
>> (fsal_obj_ops->io_advise), so applications running on top of NFS will
>> benefit. I failed to see if the standard Samba/vfs can use it.
>>
>> A quick check in QEMU does not suggest it is used by the block drivers.
>>
>> I don't think Linux/FUSE supports fadvise though. So this is an
>> oppertunity for a Gluster developer to get their name in the Linux
>> kernel :-) Feature additions like this have been done before by us, and
>> we should continue where we can. It is a relatively easy entry for
>> contributing to the Linux kernel.
>>
>
> To me it looks like fadvise (mm/fadvise.c) affects only the linux page
> cache behavior and is decoupled from the filesystem itself. What this means
> for fuse  is that the  'advise' is only to the content that the fuse kernel
> module has stored in that machine's page cache.  Exposing it as a FOP would
> likely involve adding a new fop to struct file_operations that is common
> across the entire VFS and likely  won't fly with the kernel folks. I could
> be wrong in understanding all of this. :-)
>

That's correct. file_operations don't have fadvise and hence exposing this
to underlying filesystems would require adding this member.


> Regards,
> Ravi
>
>
>>
>>> [1] https://linux.die.net/man/2/fadvise
>>>
>> As well as local man-pages for fadvise64/posix_fadvise.
>>
>> Showing that we have support for this, suggests that the filesystem
>> becomes more mature and gains advanced features. This should impress
>> users and might open up more interest for certain (HPC?) use-cases.
>>
>> Thanks,
>> Niels
>>
>>
>> regards,
>>> Raghavendra
>>> ___
>>> 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
>>
>
> ___
> Gluster-devel mailing list
> Gluster-devel@gluster.org
> http://lists.gluster.org/mailman/listinfo/gluster-devel
>



-- 
Raghavendra G
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] Question regarding to gluster and vfs

[Raghavendra G]

On Thu, Aug 17, 2017 at 5:16 PM, Shyam Ranganathan 
wrote:

> On 08/17/2017 07:36 AM, Amar Tumballi wrote:
>
>>
>>
>> On Thu, Aug 17, 2017 at 1:21 PM, Raghavendra Talur > > wrote:
>>
>> On Wed, Aug 16, 2017 at 5:52 PM, Ilan Schwarts > > wrote:
>>  > Hi,
>>  > So this is a bit odd case.
>>  > I have created 2 servers nodes (running CentOS 7.3)
>>  > From Client machine (CentOS 7.2) I mount to one of the nodes
>> (nfs) using:
>>  > [root@CentOS7286-64 mnt]#  mount -t nfs
>>  > L137B-GlusterFS-Node1.L137B-root.com:/volume1 /mnt/glustervianfs/
>>  >
>>  > When i created (touch) a file over the NFS:
>>  > From Client Machine:
>>  > [revivo@CentOS7286-64 glustervianfs]$ touch nfs3file
>>  > [revivo@CentOS7286-64 glustervianfs]$ id revivo
>>  > uid=2021(revivo) gid=2020(maccabi) groups=2020(maccabi),10(wheel)
>>  >
>>  > On Server machine:
>>  > I monitor the file operations at VFS kernel level.
>>  > I receive 1 event of file create, and 2 events of set attribute
>> changes.
>>  > What I see is that root creates the file (uid/gid of 0)
>>  > And then root (also) use chown and chgrp to set security
>> (attribute)
>>  > of the new file.
>>  >
>>  > When i go to the glutser volume itself and ls -la,i do see the
>>  > *correct* (2021 - revivo /2020 - revivo) uid/gid:
>>  > [root@L137B-GlusterFS-Node1 volume1]# ls -lia
>>  > total 24
>>  > 11 drwxrwxrwx.  3 revivo maccabi 4096 Aug 10 12:13 .
>>  >  2 drwxr-xr-x.  3 root   root4096 Aug  9 14:32 ..
>>  > 12 drw---. 16 root   root4096 Aug 10 12:13 .glusterfs
>>  > 31 -rw-r--r--.  2 revivo maccabi0 Aug 10 12:13 nfs3file
>>  >
>>  > Why on the VFS layer i get uid/gid - 0/0
>>
>> As you have pointed out above, the file is created with 0:0
>> owner:group but subsequent operations change owner and group using
>> chown and chgrp. This is because the glusterfsd(brick daemon) process
>> always runs as root. I don't know the exact reason why setfsuid and
>> setfsgid are not used although the code exist.
>>
>> Amar/Pranith/Raghavendra/Vijay,
>>
>> Do you know why HAVE_SET_FSID is undefined in line
>> https://github.com/gluster/glusterfs/blob/master/xlators/sto
>> rage/posix/src/posix.c#L65
>> > orage/posix/src/posix.c#L65>
>>
>>
>> Its been ~10 years since its disabled in codebase, and I don't recollect
>> why completely right now.
>>
>> By checking the patch [1] which got this change, I couldn't make out
>> much: Probably something to do with Solaris support IMO.
>>
>> [1] - https://github.com/gluster/historic/commit/3176ddf99f701412b
>> d799cc730afd598c2a13e39
>>
>> May be time to run a test by removing that line as we are friendly with
>> only Linux/BSD right now.
>>
>
> From memory (so take it with a pinch of salt), setting internal xattrs and
> the like needed root permissions, and not UID/GID permissions, this was
> when parts of DHT xattr setting was fixed and this code path analyzed
> (about less than a year back).
>
> So when testing it out this possibly needs some consideration. @Nithya do
> you have a better context to provide?
>

These scenarios are explicitly handled by setting uid/gid to 0 while doing
these operations (like linkto file creation etc). Even if we run into bugs
after removing this, explicit setting of credentials should be preferred.


>
>> Regards,
>> Amar
>>
>> Thanks,
>> Raghavendra Talur
>>
>>
>>
>>
>> --
>> Amar Tumballi (amarts)
>>
>>
>> ___
>> 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
>



-- 
Raghavendra G
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel