0

I have a USB disk encrypted with LUKS. Immediately after mounting the disk today, I find that a recently edited text file contains seemingly random characters. All other files that I have checked, and the directory hierarchy, appear to be normal.

What can cause this, and can such a file be recovered?

I do have a recent backup of the entire disk, and a recent version of the text file is committed to a Git archive. I am, however, interested in a fix -- as well as preventative guidance.

Improve this question
4
  • 1
    This would likely be basic filesystem corruption, and not LUKS related. LUKS operates at the block device level, it has no concept of files (it is possible for a small section of the block device to be corrupt due to LUKS, but highly unlikely). As such, I'd run filesystem repair tools and see what they come up with. Commented Sep 4, 2014 at 5:07
  • Do a memory test. Commented Sep 4, 2014 at 22:01
  • Minor, usually recoverable, file-system corruption has become a recurring problem -- seemingly correlated with the suspend mode of my laptop (and even if I 'sync' before going to sleep). I wonder if memory corruption is a known problem in these circumstances -- I haven't yet tried to test for memory corruption across a sleep. I wonder if there is a simple way to flush all caches and reload from disk. Commented Sep 17, 2014 at 19:41
  • I have had some success with fixing seemingly broken file systems (directories reported empty after a suspend) by running the memory test posted below -- presumably as a way of flushing disk caches. Not sure if this is related to the original reported problem (a garbled file), which has only occurred one time (knock-on-wood). A hypothesis about the garbled file is that I saved the file to a confused file system and this resulted in the corruption. Commented Sep 26, 2014 at 15:01

2 Answers 2

Reset to default
0

Here's a quick-and-dirty memory test, written in 'C'. If the disk corruption is due to a memory failure, this might be an easy way to check for that.

Be careful, this will lock up your computer (with virtual memory thrashing) if you attempt to test significantly more memory than is readily available.

time { make -s CFLAGS="-Wall -Werror -std=c99" mymemtest && free -m && ./mymemtest && free -m && echo "PASS" || echo "FAIL" ; } 
 #include <stdio.h> #include <stdlib.h> #include <stdint.h> #include <assert.h> int main() { fprintf(stderr,"\n"); fprintf(stderr,"sizeof(int)=%ld, sizeof(void*)=%ld\n", sizeof(int), sizeof(void*) ); double TESTSIZE = 2.2; // amount of memory to test in GB uint64_t K=1024; // used to define a GB typedef uint64_t T; uint64_t sizebytes=TESTSIZE*K*K*K; uint64_t size = sizebytes/sizeof(T); T * a = malloc(sizebytes); assert( a != NULL ); fprintf(stderr,"sizebytes=%ld, size=%ld, chunk size=%ld, test size=%g GB\n", sizebytes, size, sizeof(T), sizebytes/(double)(K*K*K) ); fprintf(stderr,"writing...\n"); for ( uint64_t i=0; i<size; i++ ) a[i] = i; fprintf(stderr,"checking...\n"); for ( uint64_t i=0; i<size; i++ ) assert( a[i] == (T)i ); fprintf(stderr,"writing...\n"); for ( uint64_t i=0; i<size; i++ ) a[i] = 0; fprintf(stderr,"checking...\n"); for ( uint64_t i=0; i<size; i++ ) assert( a[i] == (T)0 ); fprintf(stderr,"writing...\n"); for ( uint64_t i=0; i<size; i++ ) a[i] = -1; fprintf(stderr,"checking...\n"); for ( uint64_t i=0; i<size; i++ ) assert( a[i] == (T)-1 ); fprintf(stderr,"writing...\n"); for ( uint64_t i=0; i<size; i++ ) a[i] = 0x5A5A5A5A5A5A5A5AUL; fprintf(stderr,"checking...\n"); for ( uint64_t i=0; i<size; i++ ) assert( a[i] == (T)0x5A5A5A5A5A5A5A5AUL ); fprintf(stderr,"writing...\n"); for ( uint64_t i=0; i<size; i++ ) a[i] = 0xA5A5A5A5A5A5A5A5UL; fprintf(stderr,"checking...\n"); for ( uint64_t i=0; i<size; i++ ) assert( a[i] == (T)0xA5A5A5A5A5A5A5A5UL ); free(a); fprintf(stderr,"\n"); return 0; }
Improve this answer
1
  • This test always passes for me. Commented Sep 5, 2014 at 17:03
0

file system confusion after suspend (Ubuntu 13.10)

I have isolated recurring file system problems to correlate with suspending my laptop while the LUKS-encrypted USB disk is mounted. Commonly, it thinks that whatever directory I had open in a terminal is now empty after resuming from suspend. It seems likely that saving a file to such a directory could result in corruption (but this has only happened once). My typical solution is to unmount the disk before suspending, but sometimes I forget to do this.

I have found that purging the cache fixes the file system after resume:

sudo sh -c 'echo 3 >/proc/sys/vm/drop_caches'

It might still be wise to run sync before suspending...

Improve this answer
6
  • scary if true... you should investigate further how/why that happens. Commented Oct 18, 2014 at 19:49
  • Update: Purging the cache seems to help, but is not a complete solution. Commented Nov 4, 2014 at 16:48
  • Fingers crossed, but I have not observed this problem since upgrading Ubuntu from 13.10 to 14.04 LTS. Commented Nov 20, 2014 at 2:36
  • ...Looks like 14.04 LTS has problems too. Commented Dec 7, 2014 at 17:51
  • My current method of dealing with this is to use the Disks utility to "Unmount the filesystem" without locking the encrypted device. Then I can remount with one click -- not requiring the password. Commented Dec 11, 2014 at 19:02

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.