EcryptFS development
 help / color / mirror / Atom feed
From: Martin Steigerwald <ms@teamix.de>
To: Alexis Hafner <alexis.hafner@gmail.com>
Cc: Tyler Hicks <tyhicks@canonical.com>,
	"ecryptfs@vger.kernel.org" <ecryptfs@vger.kernel.org>
Subject: Re: ecryptfs_write_metadata: Error writing metadata out to lower file; rc = [-13]
Date: Tue, 20 Dec 2011 13:27:10 +0100	[thread overview]
Message-ID: <201112201327.11445.ms@teamix.de> (raw)
In-Reply-To: <-573303501705934429@unknownmsgid>

Am Dienstag, 20. Dezember 2011 schrieb Alexis Hafner:
> Le 20 déc. 2011 à 02:06, Tyler Hicks <tyhicks@canonical.com> a écrit :
> > On 2011-12-19 13:26:19, Martin Steigerwald wrote:
> >> Hi!
> >> 
> >> Today I tested again whether ecryptfs would be suitable to replace encfs
> >> on my
> > 
> >> laptop. But I found several problems. The blocking one is:
> > Sorry, hopefully we can get them straightened out.
> > 
> >> ms@merkaba:~/Training/TXS-svn/Linux_15_Performance_Tuning#2> LANG=C make
> >> […]
> >> sed: couldn't open temporary file ./sedhqlAcd: Permission denied
> >> […]
> >> 
> >> ms@merkaba:~/Training/TXS-svn/Linux_15_Performance_Tuning> LANG=C ls -l
> >> | tail -6
> >> ls: cannot access sedhqlAcd: No such file or directory
> >> ls: cannot access sedChky0a: No such file or directory
> >> ls: cannot access sed1eW8Ek: No such file or directory
> >> ls: cannot access sedEjR2oA: No such file or directory
> >> ls: cannot access sedb4JEiI: No such file or directory
> >> ls: cannot access sedy0KQnt: No such file or directory
> >> -?????????  ? ?  ?            ?            ? sedChky0a
> >> -?????????  ? ?  ?            ?            ? sedEjR2oA
> >> ----------  1 ms teamix 1143445 Dec  5 10:01 sedNL1bTk
> >> -?????????  ? ?  ?            ?            ? sedb4JEiI
> >> -?????????  ? ?  ?            ?            ? sedhqlAcd
> >> -?????????  ? ?  ?            ?            ? sedy0KQnt
> >> 
> >> 
> >> Output in dmesg is:
> >> 
> >> ms@merkaba:~/Training/TXS-svn/Linux_15_Performance_Tuning> sudo tail -2
> >> /var/log/syslog
> >> Dec 19 13:23:30 merkaba kernel: [50999.570071] ecryptfs_write_metadata:
> >> Error writing metadata out to lower file; rc = [-13]
> >> Dec 19 13:23:30 merkaba kernel: [50999.570083] Error writing headers; rc
> >> = [-13]
> >> 
> >> 
> >> Ecryptfs is configured as follows:
> >> 
> >> merkaba:~> cat .ecryptfsrc
> >> ecryptfs_unlink_sigs
> >> ecryptfs_sig=[…]
> >> ecryptfs_fnek_sig=[…]
> >> ecryptfs_xattr
> >> ecryptfs_key_bytes=32
> >> ecryptfs_cipher=aes
> >> ecryptfs_passthrough=n
> >> 
> >> I am using extended attributes to avoid the space waste of 8 KiB per
> >> file.
> > 
> > I must warn you that the ecryptfs_xattr_metadata option is rarely used
> > by anyone and gets little testing from me upstream. I understand the
> > desire to save some space, but you should also consider stability here.
> > I'm working to automate some of that testing soon, so there is hope that
> > things could get better in this area.
[…]
> I can report the same bug on a 64-bits Rhel server 6.2 machine running
> the default Red Hat kernel, also with ext4 as the lower file-system :
> using extended attributes fails with the same error logs. This could
> indicate that the problem is not limited to the last development
> kernels, but has been here a little longer.

Can you also reproduce the rsync copies twice issue I reported in the other 
thread? Does the bug disappear when storing metadata in files instead.

Would be nice to have confirmation for that as well.

Thanks,
-- 
Martin Steigerwald - teamix GmbH - http://www.teamix.de
gpg: 19E3 8D42 896F D004 08AC A0CA 1E10 C593 0399 AE90

      reply	other threads:[~2011-12-20 12:27 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-12-19 12:26 ecryptfs_write_metadata: Error writing metadata out to lower file; rc = [-13] Martin Steigerwald
2011-12-20  1:06 ` Tyler Hicks
2011-12-20  8:46   ` Martin Steigerwald
2011-12-20  9:45     ` Martin Steigerwald
2011-12-20 12:05   ` Alexis Hafner
2011-12-20 12:27     ` Martin Steigerwald [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=201112201327.11445.ms@teamix.de \
    --to=ms@teamix.de \
    --cc=alexis.hafner@gmail.com \
    --cc=ecryptfs@vger.kernel.org \
    --cc=tyhicks@canonical.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox