Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 8 Dec 1997 08:24:49 +0100 (MET)
From:      Søren Schmidt <sos@FreeBSD.dk>
To:        julian@whistle.com (Julian Elischer)
Cc:        hackers@FreeBSD.ORG, julian@whistle.com, mckusick@mckusick.com
Subject:   Re: [hackers:] Architectural advice needed
Message-ID:  <199712080724.IAA01786@sos.freebsd.dk>
In-Reply-To: <Pine.BSF.3.95.971207202900.20555A-100000@current1.whistle.com> from Julian Elischer at "Dec 7, 97 09:46:34 pm"

next in thread | previous in thread | raw e-mail | index | archive | help
In reply to Julian Elischer who wrote:
> This starts out discussing a single problem and then goes on to discuss
> more general problems and ideas.. stick with it..
> 
> BDE pointed out a problem in the system that showed up when using my
> device filesystem.  In spec_getpages() the size of the device's blocks is
> incorrectly deduced from the blocksize of the filesystem in which the
> device resided (e.g. if you are accessing sd2 with a blocksize of 1K, you
> will get 512 bytes because /dev/ is in / and THAT is on sd0 and has a
> blocksize of 512 bytes.) This so obvioously wrong that i'm not worried
> about whether it SHOULD be fixed, just HOW? 

Wrong, if a filesystem is mounted, it uses the mnt_stat.f_bsize instead.
This is endeed an ugly hack (I put it there to accomodate devices with
!= 512 byt sectors). Either we let it stay at all times at 512 bytes and
let the device driver chain cope with that, or we use the actual size
of the device throughout the 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...

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Søren Schmidt               (sos@FreeBSD.org)               FreeBSD Core Team
                Even more code to hack -- will it ever end
..



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199712080724.IAA01786>