From owner-cvs-all Sat Mar 30 8: 5:58 2002 Delivered-To: cvs-all@freebsd.org Received: from freefall.freebsd.org (unknown [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 3A11C37B404; Sat, 30 Mar 2002 08:05:55 -0800 (PST) Received: (from bde@localhost) by freefall.freebsd.org (8.11.6/8.11.6) id g2UG2iH91829; Sat, 30 Mar 2002 08:02:44 -0800 (PST) (envelope-from bde) Message-Id: <200203301602.g2UG2iH91829@freefall.freebsd.org> From: Bruce Evans Date: Sat, 30 Mar 2002 08:02:44 -0800 (PST) To: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: cvs commit: src/sys/kern subr_disklabel.c X-FreeBSD-CVS-Branch: HEAD Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG bde 2002/03/30 08:02:44 PST Modified files: sys/kern subr_disklabel.c Log: Fixed handling of short reads in readdisklabel() and writedisklabel(). These functions use DEV_STRATEGY() which can easily return a short count (with no error) for reads near EOF. EOF happens for "disks" too small to contain a label sector (mainly for empty slices). The functions didn't understand this at all, and looked for labels in the garbage in the buffer beyond what DEV_STRATEGY() returned. The recent UMA changes combined with my local changes and configuration resulted in the garbage often containing a valid but garbage label left over from a previous call. Bugs in EOF handling in -current limited the problem to "disks" with size precisely LABELSECTOR sectors. LABELSECTOR happens to be a very unusual "disk" size since it is only 0 for non-i386 arches that don't usually have disks with DOS MBRs. Revision Changes Path 1.63 +6 -0 src/sys/kern/subr_disklabel.c To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message