From owner-freebsd-hackers Wed Sep 25 11:40:11 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 23D8637B404 for ; Wed, 25 Sep 2002 11:40:09 -0700 (PDT) Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7AB1F43E6E for ; Wed, 25 Sep 2002 11:40:08 -0700 (PDT) (envelope-from julian@elischer.org) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020925184008.WISU16629.rwcrmhc51.attbi.com@InterJet.elischer.org>; Wed, 25 Sep 2002 18:40:08 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id LAA47081; Wed, 25 Sep 2002 11:29:13 -0700 (PDT) Date: Wed, 25 Sep 2002 11:29:12 -0700 (PDT) From: Julian Elischer To: Mark Santcroos Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: vmware reads disk on non-sector boundary In-Reply-To: <20020925173453.GA1347@laptop.6bone.nl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG vmware used the blocking ("b" devices) interface to disks that do blocking for you. Some well meaning but misguided individuals removed block devices without providing an alernate way of doing this. It should be possible to do the equivalent of a vn device that accepts misalligned accesses and reblocks them, but I'll leave that to those whose job it is to finish. On Wed, 25 Sep 2002, Mark Santcroos wrote: > Vmware2 stopped running from both md and ad devices. Virtual disks still > work. It is caused by a read that is not on sector boundary. > > Should a program be able to read non-sector sized chunks from a raw disk > yes or no? What is the desired behaviour? The desired bahaviour is that it works. No programs shouldn't do it, but they sometimes do, particularly LINUX programs.. (e.g. vmware) and the chances that we get linux authors to change is really small. (Particulary vmware who have been particularly stubborn) > > The fact that this did work, was it a bug or did this come out due to some > other change. The stacktrace from read(2) is below. > > Any input welcome, it's about time that vmware runs again on -current. > > Mark > > > dscheck(c7528a70,c0c20800,4,c7528a70,c28f0800) at dscheck > diskstrategy(c7528a70,10,4,c0c20800,c0c2086c) at diskstrategy+0x7f > readdisklabel(c23f4e00,c28f0800,1,c23d4000,c23f4e4c) at readdisklabel+0xb8 > dsopen(c2347e00,2000,0,c23d9588,c23d9200) at dsopen+0x1e6 > diskopen(c2347e00,1,2000,c23e0cc0,c26c4700) at diskopen+0x15f > spec_open(cdac9a2c,cdac9ac8,c027796b,cdac9a2c,c0911c50) at spec_open+0x150 > spec_vnoperate(cdac9a2c,c0911c50,1,100,c23e0cc0) at spec_vnoperate+0x18 > vn_open_cred(cdac9bcc,cdac9ccc,0,c26c4700,cdac9cb8) at vn_open_cred+0x3eb > vn_open(cdac9bcc,cdac9ccc,0,1,cdac9b04) at vn_open+0x29 > kern_open(c23e0cc0,8048639,0,1,0) at kern_open+0x1e3 > open(c23e0cc0,cdac9d10,c,c23e0cc0,3) at open+0x30 > syscall(2f,2f,2f,bfbffae4,bfbffaec) at syscall+0x2ca > Xint0x80_syscall() at Xint0x80_syscall+0x1d > > -- > Mark Santcroos RIPE Network Coordination Centre > http://www.ripe.net/home/mark/ New Projects Group/TTM > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message