linux-ext4 - Re: ext4 error when testing virtio-scsi & vhost-scsi

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: <CAMj5Bkhr3aLTRtb58xsZGwZWchFb95bdZ8NbiLEfG=vmoObxkQ@mail.gmail.com>
Date:	Fri, 15 Jul 2016 15:55:20 +0800
From:	Zhangfei Gao <zhangfei.gao@...il.com>
To:	Dave Chinner <david@...morbit.com>
Cc:	"Theodore Ts'o" <tytso@....edu>, kvm@...r.kernel.org,
	qemu-devel@...gnu.org, target-devel@...r.kernel.org,
	linux-ext4@...r.kernel.org
Subject: Re: ext4 error when testing virtio-scsi & vhost-scsi

Dear Dave

On Wed, Jul 13, 2016 at 7:03 AM, Dave Chinner <david@...morbit.com> wrote:
> On Tue, Jul 12, 2016 at 12:43:24PM -0400, Theodore Ts'o wrote:
>> On Tue, Jul 12, 2016 at 03:14:38PM +0800, Zhangfei Gao wrote:
>> > Some update:
>> >
>> > If test with ext2, no problem in iblock.
>> > If test with ext4, ext4_mb_generate_buddy reported error in the
>> > removing files after reboot.
>> >
>> >
>> > root@(none)$ rm test
>> > [   21.006549] EXT4-fs error (device sda): ext4_mb_generate_buddy:758: group 18
>> > , block bitmap and bg descriptor inconsistent: 26464 vs 25600 free clusters
>> > [   21.008249] JBD2: Spotted dirty metadata buffer (dev = sda, blocknr = 0). Th
>> > ere's a risk of filesystem corruption in case of system crash.
>> >
>> > Any special notes of using ext4 in qemu?
>>
>> Ext4 has more runtime consistency checking than ext2.  So just because
>> ext4 complains doesn't mean that there isn't a problem with the file
>> system; it just means that ext4 is more likely to notice before you
>> lose user data.
>>
>> So if you test with ext2, try running e2fsck afterwards, to make sure
>> the file system is consistent.
>>
>> Given that I'm reguarly testing ext4 using kvm, and I haven't seen
>> anything like this in a very long time, I suspect the problemb is with
>> your SCSI code, and not with ext4.
>
> It's the same error I reported yesterday for ext3 on 4.7-rc6 when
> rebooting a VM after it hung.


Any link of this error?

Now I still can not get conclusion of which part cause this error?

1. No problem
a. Using with virtio-scsi, and test via files with ext4 filesystem, no problem.

 /work/qemu.git/aarch64-softmmu/qemu-system-aarch64 \
    -enable-kvm -nographic -kernel Image \
    -global virtio-blk-device.scsi=on -device virtio-scsi-device,id=scsi \
    -drive file=ext4_oe64.img,id=coreimg,cache=none,if=none,format=raw \
    -device scsi-hd,drive=coreimg \
    -m 512 -M virt -cpu host \
    -append "earlyprintk console=ttyAMA0 mem=512M"

ext4_oe64.img is ext4 file system.

b. Use vhost-scsi & target, ramdisk as backstore, ext4 filesystem,
also no problem.


2. Has problem
a. Using vhost-scsi & target, iblock, with sas disk & u-disk as
backstore, ext4, both has issue.
it only prove the issue is not in driver (sas & u-disk) itself.


Looks the issue is in vhost-scsi & target.
Still in checking how to narrow down.

Any suggestion?


Thanks
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html