[Gluster-users] rot-13 Translator query

[Ravishankar N]

On 10/16/2016 02:40 PM, Ankireddypalle Reddy wrote:
>
> The encryption xlator is the last one before posix and it’s here that 
> the data is getting encrypted.  When the data is read back the 
> encrypted data is returned. Decryption is supposed to happen in read 
> callback which does not seem to be happening. The fact that encrypted 
> data is getting returned indicates that data in turn is getting 
> returned from the posix/underlying fs layer.  Is it possible that data 
> be returned by reading from the underlying fs by any translator other 
> than posix.
>
No, rot13_readv() just winds it to the xlator below (posix) and decrypts 
the read in the cbk. Have you tried disabling the perf xlators on the 
client like I suggested? You can see if client3_3_readv() is hit on the 
client (mount) process when you read the file. If it is and despite it, 
posix_readv is not hit on the brick, then something fishy is going on.
-Ravi


> Thanks and Regards,
>
> Ram
>
> *From:*Ravishankar N [mailto:ravishankar at redhat.com]
> *Sent:* Sunday, October 16, 2016 12:19 AM
> *To:* Ankireddypalle Reddy; gluster-users at gluster.org
> *Subject:* Re: [Gluster-users] rot-13 Translator query
>
> On 10/15/2016 08:22 PM, Ankireddypalle Reddy wrote:
>
>     Hi,
>
>           I am trying to follow the below document for developing a
>     translator.
>
>     https://github.com/gluster/glusterfs/blob/master/doc/developer-guide/translator-development.md
>
>           I’ve created a replica volume and modified the vol file to
>     include rot-13 translator. Below is the snippet from vol file.
>
>     volume myvol-posix
>
>         type storage/posix
>
>         option volume-id b492191e-77a5-4fc3-9394-49218e36dae2
>
>         option directory /brick1/repli
>
>     end-volume
>
>     volume *myvol-rot13*
>
>         type encryption/rot-13
>
>         subvolumes *myvol-posix*
>
>     end-volume
>
>     volume myvol-trash
>
>         type features/trash
>
>         option trash-internal-op off
>
>         option brick-path /brick1/repli
>
>         option trash-dir .trashcan
>
>         subvolumes *myvol-rot13*
>
>     end-volume
>
>     …
>
>     The writes are getting intercepted by the translator and the file
>     is getting encrypted. But the reads don’t seem to be getting
>     intercepted by the translator.  I tried setting break point in the
>     posix_readv function and attach the brick daemons to gdb. But
>     posix_readv does not seem to be getting called on the brick daemon
>     and the read completes on the application side.
>
>     Can someone please explain how the reads are getting serviced here
>     without hitting the posix layer.
>
> It could be due to client side caching. I usually disable all 
> performance xlators (write-behind, read-head, io-cache, stat-prefetch, 
> quick-read, open-behind) when I want to remove caching effects while 
> debugging. drop-caches also helps.
>
> HTH,
> Ravi
>
>
> Thanks and Regards,
>
> Ram
>
> ***************************Legal Disclaimer***************************
>
> "This communication may contain confidential and privileged material 
> for the
>
> sole use of the intended recipient. Any unauthorized review, use or 
> distribution
>
> by others is strictly prohibited. If you have received the message by 
> mistake,
>
> please advise the sender by reply email and delete the message. Thank 
> you."
>
> **********************************************************************
>
>
> _______________________________________________
> Gluster-users mailing list
> Gluster-users at gluster.org <mailto:Gluster-users at gluster.org>
> http://www.gluster.org/mailman/listinfo/gluster-users
>
> ***************************Legal Disclaimer***************************
> "This communication may contain confidential and privileged material 
> for the
> sole use of the intended recipient. Any unauthorized review, use or 
> distribution
> by others is strictly prohibited. If you have received the message by 
> mistake,
> please advise the sender by reply email and delete the message. Thank 
> you."
> **********************************************************************


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.gluster.org/pipermail/gluster-users/attachments/20161016/eef2454c/attachment.html>