linux-kernel - Re: testing result of loop-aio patchset on ext3

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.LFD.2.00.1407141142520.13527@localhost.localdomain>
Date:	Mon, 14 Jul 2014 11:51:16 +0200 (CEST)
From:	Lukáš Czerner <lczerner@...hat.com>
To:	Rui Xiang <rui.xiang@...wei.com>
cc:	Dave Kleikamp <dave.kleikamp@...cle.com>,
	linux-ext4@...r.kernel.org, linux-fsdevel@...r.kernel.org,
	linux-kernel@...r.kernel.org, Li Zefan <lizefan@...wei.com>
Subject: Re: testing result of loop-aio patchset on ext3

On Mon, 14 Jul 2014, Rui Xiang wrote:

> Date: Mon, 14 Jul 2014 17:34:38 +0800
> From: Rui Xiang <rui.xiang@...wei.com>
> To: Dave Kleikamp <dave.kleikamp@...cle.com>, linux-ext4@...r.kernel.org
> Cc: linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
>     Li Zefan <lizefan@...wei.com>
> Subject: testing result of loop-aio patchset on ext3
> 
> Hi Dave,
> 
> We export a container image file as a block device via loop device, but we
> found it's very easy that the container rootfs gets corrupted due to power
> loss.
> 
> Your early version of loop-aio patchset said the patchset can make loop
> mounted filesystems recoverable(lkml.org/lkml/2012/3/30/317), but we found
> it doesn't help.
> 
> Both the guest fs and host fs are ext3.
> 
> The loop-aio patchset is from:
> git://github.com/kleikamp/linux-shaggy.git aio_loop
> 
> Steps:
> 1. dd a 10G image, mkfs.ext3,
>   # dd if=/dev/zero of=./raw_image bs=1M count=10000
>   # echo y | mkfs.ext3 raw_image
> 
> 2. losetup a loop device, mount at ./test_dir
>   # losetup /dev/loop1 raw_image
>   # mount /dev/loop1 ./test_dir
> 
> 3. copy fs_mark into test_dir and run
>   # ./fs_mark -d ./tmp/ -s 102400000 -n 80
> 
> 4. during runing fs_mark, make systerm reboot indirectly.
>   # echo b > /proc/sysrq-trigger
> 
> After systerm booted up, sometimes fsck reported raw_image fs has been damaged.
> 
> # fsck.ext3 -n raw_image
> e2fsck 1.41.9 (22-Aug-2009)
> Warning: skipping journal recovery because doing a read-only filesystem check.
> raw_image contains a file system with errors, check forced.
> Pass 1: Checking inodes, blocks, and sizes
> Pass 2: Checking directory structure
> Pass 3: Checking directory connectivity
> Pass 4: Checking reference counts
> Pass 5: Checking group summary information
> Free blocks count wrong (2481348, counted=2480577).
> Fix? no
> Free inodes count wrong (640837, counted=640835).
> Fix? no
> raw_image: ********** WARNING: Filesystem still has errors **********
> raw_image: 11/640848 files (0.0% non-contiguous), 78652/2560000 blocks

It's not damaged, this is expected result if you're using old
e2fsprogs which still treats this as an error.

It's not an error because we only update superblock summary at
unmount time so with unclean shutdown it's likely that it does not
match the reality, but e2fsck can and will easily fix that for you.

Please try e2fsprogs v1.42.3 or newer.

Thanks!
-Lukas

> 
> 
> With a specific script, I can almost 100% reproduce this issue.
> 
> And it seems the corruption can only happen when reboot happens at the
> time loop is calling vfs_fsync().
> 
> Do you have any idea why the loop-aio patchset doesn't help?
> 
> Thanks.
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/