Date: Tue, 31 Oct 1995 20:51:19 +1700 (MST) From: Terry Lambert <terry@lambert.org> To: msmith@atrad.adelaide.edu.au (Michael Smith) Cc: terry@lambert.org, msmith@atrad.adelaide.edu.au, lenzi@cwbone.bsi.com.br, hackers@FreeBSD.org Subject: Re: boot disk.... Message-ID: <199511010351.UAA11237@phaeton.artisoft.com> In-Reply-To: <199511010138.MAA05178@genesis.atrad.adelaide.edu.au> from "Michael Smith" at Nov 1, 95 12:07:59 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > > > Why? We don't *have* to insist that we be able to boot from an 'a' slice > > > > after 1024, do we? That's a requirement you've tacked on. > > > > > > It's becoming a very common requirement 8( > > > > It's one that DOS and Win95 don't meet. That's 80% or more of Intel class > > machines right there -- doesn't seem very common. > > You miss my point. Joe Luser wants FreeBSD on his w95 machine. Us nice > people talk him into using fips to shrink his 1.6GB FAT filesystem (stop > puking Terry 8) down to "as small as possible". > > He comes back and complains that he can't boot. > > After a week of confusing replies we discover that because he has seperate > copies of every version of Doom ever released, and more than two > Microsoft products, "as small as possible" is still >1024 cylinders. Well, then he's "Doom"ed. 8-) 8-). > We should be able to work in this situation; the fact that it's almost > impossible notwithstanding. We can. All you have to do is use the 386BSD protected mode wd second stage boot code. Won't work for most SCSI devices, but that's not a problem... we are talking IDE here. The question is, how will you get the DOS MBR to read past cylinder 1024 when the DOS MBR only has 10 bits for cylinder number in the I/O interface it *must* use? > > Media perfection impact write ordering algorithms. As such, it must be > > visible to the upper layer I/O subsystem, even if it is infact implemented > > in hardware. > > I think that the nightmare that would be involved in attempting to outthink > a modern SCSI drive's behaviour in the presence of forwarded sectors would > cost more than it would save. Not true. In a striping or RAID case, you *want* to ensure contiguity of extents. sector relocation in hardware is actually a bad thing. Unless you use the SCSI II commands to ask about where it has taken place and adjust your clustered I/O code accordingly. NTFS actually does this. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199511010351.UAA11237>