Hi Tyler, 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. Alexis 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. > >> >> The underlying filesystem is: >> >> merkaba:~> grep /home /proc/mounts >> /dev/mapper/merkaba-home /home ext4 >> rw,noatime,user_xattr,acl,barrier=1,stripe=128,data=ordered 0 0 >> /home/.ms /home/ms ecryptfs >> rw,relatime,ecryptfs_fnek_sig=[…],ecryptfs_sig=[…],ecryptfs_cipher=aes,ecryptfs_key_bytes=32,ecryptfs_xattr_metadata,ecryptfs_unlink_sigs >> 0 0 >> >> Kernel is: >> >> ms@merkaba:~> cat /proc/version >> Linux version 3.2.0-rc4-amd64 (Debian 3.2~rc4-1~experimental.1) > > Ok, I was able to reproduce this on roughly the same kernel version by > untar'ing the kernel source. > > I'll have to do some more investigation into how we can handle this > error better. ext4 is returning an error when we're trying to create the > xattr upon file creation, so how we convey that to userspace through the > creat() return value and how we clean up after ourselves is probably the > issue here. > > Tyler > >> (ben@xxxxxxxxxxxxxxx) (gcc version 4.6.2 (Debian 4.6.2-5) ) #1 SMP Sun Dec 4 >> 18:38:24 UTC 2011 >> >> >> With encfs or from my local workstation via NFS there is no such issue. >> >> Ciao, >> -- >> 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 -- 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