Date: Mon, 8 Dec 1997 10:20:12 +0100 (MET) From: Søren Schmidt <sos@FreeBSD.dk> To: julian@whistle.com (Julian Elischer) Cc: sos@FreeBSD.dk, hackers@FreeBSD.ORG, mckusick@mckusick.com Subject: Re: [hackers:] Architectural advice needed Message-ID: <199712080920.KAA02179@sos.freebsd.dk> In-Reply-To: <Pine.BSF.3.95.971207234113.20612H-100000@current1.whistle.com> from Julian Elischer at "Dec 8, 97 00:00:36 am"
next in thread | previous in thread | raw e-mail | index | archive | help
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
..
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199712080920.KAA02179>