From owner-freebsd-current Wed Nov 1 12: 8:49 2000 Delivered-To: freebsd-current@freebsd.org Received: from palrel1.hp.com (palrel1.hp.com [156.153.255.242]) by hub.freebsd.org (Postfix) with ESMTP id EFC8737B4CF for ; Wed, 1 Nov 2000 12:08:45 -0800 (PST) Received: from adlmail.cup.hp.com (adlmail.cup.hp.com [15.0.100.30]) by palrel1.hp.com (Postfix) with ESMTP id 52519FB7; Wed, 1 Nov 2000 12:08:25 -0800 (PST) Received: from cup.hp.com (gauss.cup.hp.com [15.28.97.152]) by adlmail.cup.hp.com (8.9.3 (PHNE_18546)/8.9.3 SMKit7.02) with ESMTP id MAA08621; Wed, 1 Nov 2000 12:08:25 -0800 (PST) Message-ID: <3A007838.25121ACC@cup.hp.com> Date: Wed, 01 Nov 2000 15:08:24 -0500 From: Marcel Moolenaar Organization: Hewlett-Packard X-Mailer: Mozilla 4.73 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Poul-Henning Kamp Cc: Andrew Gallatin , freebsd-current@FreeBSD.ORG Subject: Re: linux emulation References: <22496.973107332@critter> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Poul-Henning Kamp wrote: > > >In short: given the (u)dev_t, get the FS statistics and return the > >number of free blocks and inodes of the FS on that device. > > But the udev_t is a (32bit truncated to) 16bit one, right ? Correct. > In that case it will usually not work: > > crw-r----- 1 root operator 116, 0x00010002 1 Jan 1970 /dev/ad0 > crw-r----- 1 root operator 116, 0x00020000 1 Jan 1970 /dev/ad0s1a [snip] It won't always work. > Considering the fact that we were likely to return statistics for the > wrong filesystem with the old code, and most likely cannot return > the right statistics anyway, I think we should just return zero > for those values (or some other more sensible values) I think we should try to return the right statistics in the case where we have it wrong now instead of returning the wrong statistics in the case where we have it right now. When we have it wrong, we're likely to return zero anyway. The only case that pops up in my mind that may cause us to return the statistics of a different device than the one intended is when the minor number is a sequence and we've truncated sequence S, with S > 255 into S % 255. This is not very likely. Hmmm... the strange assignment of NFS mounts might be a problem as well (warning: vague recollections in combination with memory leaks of dated info and mental cross-talk may make this statement slightly off :-) -- Marcel Moolenaar mail: marcel@cup.hp.com / marcel@FreeBSD.org tel: (408) 447-4222 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message