Re: rot-13 Translator query

[Ravishankar N <ravishankar@xxxxxxxxxx>]

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@xxxxxxxxxx]
Sent: Sunday, October 16, 2016 12:19 AM
To: Ankireddypalle Reddy; gluster-users@xxxxxxxxxxx
Subject: Re: 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@xxxxxxxxxxx

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."

**********************************************************************

_______________________________________________
Gluster-users mailing list
Gluster-users@xxxxxxxxxxx
http://www.gluster.org/mailman/listinfo/gluster-users