Am Dienstag, 20. Dezember 2011 schrieb Tyler Hicks: > 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. Thanks for taking care. There is no hurry. Encfs basically works reliably. Only thing is, that it is slow at times and tends to use quite a bit of CPU time even on this ThinkPad T520 with Intel Sandybridge i5 and Intel SSD 320. I hope that this will be better with ecryptfs. > > 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. My other home directory has about 852550 files and there about 3,25 GiB would be wasted. Too good that I do not plan to encrypt it right now. ;) Do you now about xfstests test suite? Maybe a suitable sub selection of tests in there could help with testing ecryptfs. > > 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,ec > > ryptfs_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. Why is Ext4 returning an error? Shouldn´t it just set the attribute and thats it? Maybe it has an issue doing it upon file creation? Could an Ext4 bug be involved here? I am willing to report with to Ext4 developers if need be. 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
