If the 3ware isn't reporting verify errors, then the media is
probably good.
The symptom -- corrupted config files after a crash -- reminds me
of the ext4 data loss bug from a couple of years ago:
http://ostatic.com/blog/recent-bug-report-details-data-loss-in-ext4-tso-explains-cause-and-workarounds
Perhaps the eCryptfs has a similar (caching / slow sync) problem to
what ext4 had?
Or perhaps the crashing gconfd was the cause, and the corrupted
config files was a symptom (instead of vice versa as you described)?
I think the next step would be to try to create a reliable
reproduction of the problem. Do big dd copies / md5sums and see if you
can make it happen reliably.
Thanks,
Derek
P.S.> eCryptfs is way better than nothing, but be aware that sensitive
information may still get paged into swap or written by apps into /tmp/
or /var/log/. Full-disk encryption avoids those issues.
On 01/06/2011 05:41 PM, Phil Mocek wrote:
On Thu, Jan 06, 2011 at 05:13:20PM -0800, Brian C. Lane wrote:
On Thu, Jan 06, 2011 at 01:34:43PM -0800, Phil Mocek wrote:
I'm using eCryptfs on an Ubuntu 10.4 system with the 2.6.32-27
kernel. It was set up using the Ubuntu installer from the i386
alternative CDROM with the encrypted home directory option
enabled. Recently, I noticed several unrelated problems (mostly
surrounding gconfd segmentation faults) that I traced back to
invalid configuration files. They're dotted with control
characters that shouldn't be there.
How should I go about troubleshooting problems with eCryptfs?
Are you sure it isn't an underlying problem with the drive?
There's more than a single drive underneath, but I'm not sure that
this isn't an underlying problem. The file in which the data for
this encrypted filesystem is stored exists on an ext4 filesystem
on an LVM logical volume in a volume group which uses a physical
volume that is entirely on a RAID array. Other filesystems are
all in the same volume group, and the array is auto-verified
frequently by the 3Ware 9650SE-8LP controller. Fsck'ing each of
them -- including the one on which the encrypted fs image file is
stored -- shows no problems.
