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

Am Dienstag, 20. Dezember 2011 schrieb Martin Steigerwald:
> > > 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.
> 
> Okay. Thanks for the warning.
> 
> Why is that? Obviously it seems to me that xattr has quite some advantages?
> I  find 8 KiB per file quite some space waste. Rsync can copy xattrs so
> backup is possible. But then the directory I want to encrypt is only about
> 63600 files. That would make 508800 KiB. Well even that is about half an
> GiB. Well could be acceptable for now since its at least an 300 GB SSD.
> 
> But does it also mean more writes? Not that it should matter much. Might
> make  sense to test it this way anyway. When I understand it correctly,
> this error should not happen then. I think I will try it.

Okay, I now tried without putting metadata in extended attributes.

This works. Above issue didn´t show up.

Space waste is approximately as estimated:

merkaba:~> du -s /home/ms 
13672464        /home/ms
merkaba:~> du -s /home/ms2
13155688        /home/ms2

And generating slides for my linux trainings has become a *whole lot* faster. 
I didn't expect such a kind of performance improvement - more than twice as 
fast:

encfs:

ms@merkaba:/home/ms2/Training/TXS-svn/Linux_15_Performance_Tuning> 
/usr/bin/time -v make
[…]
        Command being timed: "make"
        User time (seconds): 40.25
        System time (seconds): 4.41
        Percent of CPU this job got: 87%
        Elapsed (wall clock) time (h:mm:ss or m:ss): 0:51.01
        Average shared text size (kbytes): 0
        Average unshared data size (kbytes): 0
        Average stack size (kbytes): 0
        Average total size (kbytes): 0
        Maximum resident set size (kbytes): 1162240
        Average resident set size (kbytes): 0
        Major (requiring I/O) page faults: 68
        Minor (reclaiming a frame) page faults: 219219
        Voluntary context switches: 428959
        Involuntary context switches: 14977
        Swaps: 0
        File system inputs: 179032
        File system outputs: 0
        Socket messages sent: 0
        Socket messages received: 0
        Signals delivered: 0
        Page size (bytes): 4096
        Exit status: 0

ecryptfs:

ms@merkaba:~/Training/TXS-svn/Linux_15_Performance_Tuning> /usr/bin/time -v 
make
[…]
        Command being timed: "make"
        User time (seconds): 42.11
        System time (seconds): 1.39
        Percent of CPU this job got: 191%
        Elapsed (wall clock) time (h:mm:ss or m:ss): 0:22.70
        Average shared text size (kbytes): 0
        Average unshared data size (kbytes): 0
        Average stack size (kbytes): 0
        Average total size (kbytes): 0
        Maximum resident set size (kbytes): 1221664
        Average resident set size (kbytes): 0
        Major (requiring I/O) page faults: 162
        Minor (reclaiming a frame) page faults: 238379
        Voluntary context switches: 7180
        Involuntary context switches: 13078
        Swaps: 0
        File system inputs: 195680
        File system outputs: 64032
        Socket messages sent: 0
        Socket messages received: 0
        Signals delivered: 0
        Page size (bytes): 4096
        Exit status: 0

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  9:45 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 [this message]
2011-12-20 12:05   ` Alexis Hafner
2011-12-20 12:27     ` Martin Steigerwald

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=201112201045.04553.ms@teamix.de \
    --to=ms@teamix.de \
    --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