From owner-freebsd-fs@FreeBSD.ORG Fri May 9 14:57:56 2003 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7264B37B401 for ; Fri, 9 May 2003 14:57:56 -0700 (PDT) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7E44943F93 for ; Fri, 9 May 2003 14:57:55 -0700 (PDT) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.9/8.12.9) with ESMTP id h49Lvsxa014821; Fri, 9 May 2003 23:57:54 +0200 (CEST) (envelope-from phk@phk.freebsd.dk) To: Lukas Ertl From: "Poul-Henning Kamp" In-Reply-To: Your message of "Fri, 09 May 2003 23:51:51 +0200." <20030509234356.T638@korben.in.tern> Date: Fri, 09 May 2003 23:57:54 +0200 Message-ID: <14820.1052517474@critter.freebsd.dk> cc: freebsd-fs@freebsd.org Subject: Re: newfs: useless/bogus check if new last block can be accessed? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 May 2003 21:57:56 -0000 In message <20030509234356.T638@korben.in.tern>, Lukas Ertl writes: >Hi fs-hackers, > >since I'm currently having fun in getting familiar with UFS/FFS and all >its related tools, I found the following piece of code in sbin/newfs/mkfs.c: > >[...] > >I quite clueless why that wtfs() call is there at all and how it should >"verify that its last block can actually be accessed". > >wtfs() is of type static void, and just calls bwrite() from libufs, >ignoring its return value. > >Anyone can shed some light on this? In the good old days, people could write any damn number they wanted in a disklabel, and the kernel would let them. This check tried to make sure that the partition length picked up from the disklabel, or entered as an argument actually makes sense as far as you can actually write to the last sector. I'm not sure if this particular bit does anything at this point in time, we may have caught the issue earlier in the process, because today disk devices actually know how large they are. syv# mdconfig -a -t malloc -s 1m -u 5 syv# diskinfo /dev/md5 /dev/md5 512 1048576 2048 syv# newfs -s 2047 md5 /dev/md5: 1.0MB (2044 sectors) block size 16384, fragment size 2048 using 1 cylinder groups of 1.00MB, 63 blks, 128 inodes. super-block backups (for fsck -b #) at: 32 syv# newfs -s 2048 md5 /dev/md5: 1.0MB (2048 sectors) block size 16384, fragment size 2048 using 1 cylinder groups of 1.00MB, 64 blks, 128 inodes. super-block backups (for fsck -b #) at: 32 syv# newfs -s 2049 md5 newfs: /dev/md5: maximum file system size is 2048 syv# -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.