From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Tokarev Subject: Re: the >1Tb block issue Date: Tue, 18 May 2010 20:51:55 +0400 Message-ID: <4BF2C5AB.7080105@msgid.tls.msk.ru> References: <4BF2B7CD.7090204@msgid.tls.msk.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit To: KVM list Return-path: Received: from isrv.corpit.ru ([81.13.33.159]:34411 "EHLO isrv.corpit.ru" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754124Ab0ERQv7 (ORCPT ); Tue, 18 May 2010 12:51:59 -0400 In-Reply-To: <4BF2B7CD.7090204@msgid.tls.msk.ru> Sender: kvm-owner@vger.kernel.org List-ID: 18.05.2010 19:52, Michael Tokarev wrote: > I just re-verified it on current stable > qemu-kvm-0.12.4. The issue is still here, > trivial to trigger. > > kvm-img create test.raw 1500G > kvm ... \ > -drive file=test.raw,if=virtio > > it fails right on the mkfs stage: > > mkfs.ext4 /dev/vdb > Writing inode tables: end_request: I/O error, dev vdb, sector 3145727872 > Buffer I/O error on device vdb, logical block 393215984 > lost page write due to I/O error on vdb > Buffer I/O error on device vdb, logical block 393215985 > ... > Buffer I/O error on device vdb, logical block 393215993 > > After that it continues the mkfs process, but I doubt it will > produce a good filesystem. A few more data point, for what it's worth. I tried running it under strace, but in that case the issue does not occur: mkfs wents on without errors. That puzzles me: timing problem? It always fails at the same place: sector 3145727872. This is - apparently - somewhere at the end of my 1500Gb file. If I hit Ctrl+C to stop it, mkfs will sit there forever, waiting for sync_file_pages. I tried both 32 and 64bit host with 64bit guest. The effect is exactly the same. > So far, only virtio has this problem. I tested with if=ide, it's > slower but it went much further without any error. It's still > running, but at this rate it will run for some hours more ;) > At least it does not spew errors like the virtio case. That seems to work, the filesystem looks healthy. /mjt