All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tyler Hicks <tyhicks@canonical.com>
To: Lance Reed <reed.r.lance@gmail.com>
Cc: ecryptfs@vger.kernel.org
Subject: Re: Can anyone confirm or deny if ecryptfs will work with a glusterfs backend?
Date: Wed, 26 Feb 2014 13:56:51 -0600	[thread overview]
Message-ID: <20140226195650.GB5056@boyd> (raw)
In-Reply-To: <loom.20140226T193240-335@post.gmane.org>

[-- Attachment #1: Type: text/plain, Size: 1695 bytes --]

On 2014-02-26 18:35:09, Lance Reed wrote:
> Tyler,
> 
> Thanks for the response!
> Red Hat Enterprise Linux Server release 6.4 (Santiago) (and Centos 6.4)
> 2.6.32-358.14.1.el6.x86_64

While I've not made any recent changes that I would expect to improve
glusterfs support, that is a somewhat old kernel and a newer version
may, obviously, have different results.

However, I should say that even if eCryptfs suddenly works on top of
glusterfs in a newer kernel, there's still a fundamental problem with
eCryptfs stacked on top of any type of remote filesystem. eCryptfs does
not expect the lower/backend filesystem to be modified by another
machine. So you could have cache coherency problems if two or more
clients are reading a file and then one of them updates the file.

Fixing the cache coherency issues would be step 2, after eCryptfs
actually starts working on top of popular remote filesystems (nfs, cifs,
glusterfs, etc.). Unfortunately, I'm not aware of anyone working on step
1 at the moment.

Tyler

> 
> I am actually planning to use this in a cloud setup.  Mostly for an internal
> shared NFS like but HA space.
> I had thought HekaFS had gone a bit dormant...(not a lot of talk since May
> 2013...)
> I will look at it again.  Thanks for the tip and taking a look.
> Any thought would be greatly appreciated.
> 
> Cheers,
> 
> Lance
> 
> 
> If this is a double post, I apologize.. oddness on email vs web interface:
> 
> 
> 
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe ecryptfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

      reply	other threads:[~2014-02-26 19:56 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-26 16:06 Can anyone confirm or deny if ecryptfs will work with a glusterfs backend? Lance Reed
2014-02-26 18:00 ` Tyler Hicks
2014-02-26 18:35   ` Lance Reed
2014-02-26 19:56     ` Tyler Hicks [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140226195650.GB5056@boyd \
    --to=tyhicks@canonical.com \
    --cc=ecryptfs@vger.kernel.org \
    --cc=reed.r.lance@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.