2009/1/22 The Doctor <dr...@virtadpt.net>: > Duncan wrote: > >>> and, if you have experiences with it, do you know what could happen >>> without fsck on an unsafely unmounted luks partition? >> >> Luks I know nothing of. Someday when I get the appropriate round tuit... > > I just gave it a try with a 32 megabyte SD card on my laptop. I set up > the LUKS volume like so: > > r...@windbringer ~:# cryptsetup -v -y -c aes-cbc-essiv:sha256 luksFormat > /dev/mmcblk0p1 > > ...opened it: > > r...@windbringer ~:# cryptsetup luksOpen /dev/mmcblk0p1 test > > ...but I wasn't able to create a ReiserFS file system: > > r...@windbringer ~:# mkreiserfs -d /dev/mapper/test > > [credits from mkreiserfs snipped] > > Guessing about desired format.. Kernel 2.6.28 is running. > reiserfs_create_journal: cannot create a journal of 8193 blocks with 18 > offset on 7456 blocks > > Oops. Too small a device, I guess. So, I tried EXT3: > > r...@windbringer ~:# mkfs.ext3 -c -L test -v /dev/mapper/test > ... > r...@windbringer ~:# mount /dev/mapper/test /mnt/disk_image > > To see what would happen, I copied a load of .jpg files over to the card > so there would be a test data set: > > r...@windbringer ~:# cp ~drwho/*.jpg /mnt/disk_image > > Then I yanked the SD card out of the slot without unmounting it or > running the luksClose command of cryptsetup. Much to my surprise, > nothing complained about it. Upon reinserting it, however, the > following appeared in the kernel message buffer: > > ... > mmc0: card cb93 removed > Buffer I/O error on device dm-3, logical block 539 > lost page write due to I/O error on dm-3 > Aborting journal on device dm-3. > Buffer I/O error on device dm-3, logical block 369 > lost page write due to I/O error on dm-3 > journal commit I/O error > mmc0: new SD card at address cb93 > mmcblk1: mmc0:cb93 S032B 29.6 MiB > mmcblk1: p1 > > Nautilus prompted me to enter the LUKS passphrase to open the device; > checking the kernel message buffer showed that the journal recovery was > complete, and the volume could be properly read. I checked the files > and none of them were corrupted. Next test: delete a few files, don't > run sync(1), yank the card, and try again. Kernel output: > > ... > mmc0: card cb93 removed > Buffer I/O error on device dm-4, logical block 419 > lost page write due to I/O error on dm-4 > Aborting journal on device dm-4. > Buffer I/O error on device dm-4, logical block 369 > lost page write due to I/O error on dm-4 > journal commit I/O error > ext3_abort called. > EXT3-fs error (device dm-4): ext3_put_super: Couldn't clean up the journal > Remounting filesystem read-only > > After plugging the card back in: > > ... > mmc0: new SD card at address cb93 > mmcblk1: mmc0:cb93 S032B 29.6 MiB > mmcblk1: p1 > kjournald starting. Commit interval 5 seconds > EXT3 FS on dm-4, internal journal > EXT3-fs: recovery complete. > EXT3-fs: mounted filesystem with ordered data mode. > > The deletions that took place before I pulled the card seemed to stay > deleted when the journal was replayed. I did this four more times to > see what would happen, and I didn't encounter any file system corruption. > > I haven't tried any other file systems yet, but if there is sufficient > interest I'll start walking through the contents of `cat > /proc/filesystems | grep -v ^nodev` > these tests seem pretty promising. i'll try out using my old 1gb usb key as testing mule is i'll have enough time this week-end and let you know about happenings.
-- dott. ing. beso
