From owner-freebsd-hackers Mon Dec 8 01:20:02 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA20845 for hackers-outgoing; Mon, 8 Dec 1997 01:20:02 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from sos.freebsd.dk (sos.freebsd.dk [195.8.129.33]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA20792 for ; Mon, 8 Dec 1997 01:19:48 -0800 (PST) (envelope-from sos@sos.freebsd.dk) Received: (from sos@localhost) by sos.freebsd.dk (8.8.8/8.8.8) id KAA02179; Mon, 8 Dec 1997 10:20:12 +0100 (MET) (envelope-from sos) Message-Id: <199712080920.KAA02179@sos.freebsd.dk> Subject: Re: [hackers:] Architectural advice needed In-Reply-To: from Julian Elischer at "Dec 8, 97 00:00:36 am" To: julian@whistle.com (Julian Elischer) Date: Mon, 8 Dec 1997 10:20:12 +0100 (MET) Cc: sos@FreeBSD.dk, hackers@FreeBSD.ORG, mckusick@mckusick.com From: Søren Schmidt Reply-to: sos@FreeBSD.dk X-Mailer: ELM [version 2.4ME+ PL30 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk In reply to Julian Elischer who wrote: > On Mon, 8 Dec 1997, S?ren Schmidt wrote: > > > > Wrong, if a filesystem is mounted, it uses the mnt_stat.f_bsize instead. > > Exactly.. this is the 100% wrong thing to do. No, not wxactly, depends on what you want to accomplish. > This represents the blocksize of the filesystem on which the > /dev directory resides. This is completely independent of the > blocksize of the device you are trying to write to. > DEVFS has a blocksize of 1 byte, though I SAY 128 for no real reason. Make devfs use 512 byte blocks then... > So therefore I started getting writes that were made to be multiples of > 128. You think this is correct? I am talking about doing the right thing, > which is somehow asking the device what it's blocksize is. Well, the system really does not handle sizes different from the size on the actual device modulo 512 bytes, that needs to change somehow. > My system here is working because I removed that code and said > > bsize = 512; > > which won't help with cdroms and other devices but at least get's me up > and going.. I could have made DEVFS report it's blocksize as 512, but that > would just bury the problem. I want to FIX it which is what this email was > about.. Well, it works on "normal" filesystems where mnt_stat.f_bsize is = 1024 in a default filesys, one can then change that to fit the device. Yes its ugly, but it came in with the != 512 byte sector stuff which somebody, i've long forgotten their names, did submit. > > This is endeed an ugly hack (I put it there to accomodate devices with > > != 512 byt sectors) > > Which it totally fails to do because everything thinks that they are 512 > byte devices, because /dev is on a 512 byte filesystem device. Well, as it is now the system can ONLY handle 512byte blocks, everything else i going to fail. UNLESS it is a true multiple of 512 and the mounted filesys has a blocksize that fits... Using less than 512 bytes will not work with the current system. > > The whole thing boils down to the question of who deals with the actual > > blocksize of the device. Either the entire system knows how to deal > > with it (as it sortof is now), or it is handled in the device/slice > > layer. I was newer able to favour one clearly above the other... > > the trouble is that you chose the wrong value to key off. > If it were the correct value, the rest of the system would behave a LOT > better. Well, depends on viewpoint I guess, for the purpose it was added it DTRT. Te real trouble is that userlevel things like fdisk newfs & disklabel need to know this too, go through the commits and locate the one where I put in the != 512 byte sector support. > (and I know I've done similar things so this is really nothing more than a > very MINOR pointy hat in your direction..) Just banging the number to 512 > would have been more correct as at least it would have been OBVIOUSLY > wrong rather than obscurely wrong. (hat awarded by BDE not me, he found > it) NO, that wouldn't work at all, that was how it was before, and it made spec_getpages fail on != 512 byte sector devices... And since there was NO easy way of getting the device block size, this hack was invented... Agreed this needs to change, but as the authors of the != 512byte sec code also found out, it has some rather serious impacts on the system. I think they worked further on getting this solved, but I've never heard from them again. Actually I think that the driver should pass on the native blocksize of the device, and the slice code should translate that into the system size be it 512 or whatever, change all the plases in the code where 512 byte size is used, well is a HUGE and errorprone job... -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Søren Schmidt (sos@FreeBSD.org) FreeBSD Core Team Even more code to hack -- will it ever end ..