Re: [gentoo-amd64] Re: Disable fsck on boot, was: How to make watchdog start earlier during bootup?

[Beso]

2009/1/22 The Doctor <drwho@××××××××.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:
>
> root@windbringer ~:# cryptsetup -v -y -c aes-cbc-essiv:sha256 luksFormat
> /dev/mmcblk0p1
>
> ...opened it:
>
> root@windbringer ~:# cryptsetup luksOpen /dev/mmcblk0p1 test
>
> ...but I wasn't able to create a ReiserFS file system:
>
> root@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:
>
> root@windbringer ~:# mkfs.ext3 -c -L test -v /dev/mapper/test
> ...
> root@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:
>
> root@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