All of lore.kernel.org
 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 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.