Am Dienstag, 20. Dezember 2011 schrieb Alexis Hafner: > Le 20 déc. 2011 à 02:06, Tyler Hicks <tyhicks@xxxxxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe ecryptfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
