9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: forsyth@plan9.cs.york.ac.uk forsyth@plan9.cs.york.ac.uk
Subject: disk partitioning
Date: Sat,  2 Sep 1995 13:34:39 -0400	[thread overview]
Message-ID: <19950902173439.u1pAnYAH4UFwhGrh1i1S3oM6RL0NGFeweKYJLH2YjHQ@z> (raw)

>>Problem is, SunOS and Plan 9 have different ideas about the size of the disk. I
>>presume this is just the operating systems reserving chunks for themselves, and
>>being "safe" in the case of poor, befuddled users like myself, but it's not
>>helping right now.

which SunOS command is showing the size?  show us the output of
format for that device, particularly:


	inquiry
	partition
		print

i do not think it has much to do with safety.
i am fairly sure that sunos is lying to make it easier for the people who
supply and replace the hardware; it is also compensating for the history of
RP06 (on a vax!) and SMD discs, and the dismal SCSI implementation on early
discs used in Suns, none of which could do bad block replacement automatically.

if you look at /etc/format.dat you might see what i mean.  they have
a host of `generic' device types (SUN0535, for instance).  the cyl
sizes are the minimum of any device that might be used as a `535 Mbyte'
disc.  the acyl value is a relic (which doesn't unfortunately mean you
can forget about it).
it's the amount of space reserved for `bad block replacement'.

now, the value printed by Plan 9's disk/prep as the size of the disc is
the value the device returned in response to a SCSI `get capacity' command.
that value will work, in the sense that blocks up to that point can
be read and written, provided the device is not in some insane state
set by a mode page (and i doubt that it is).
there is nothing to stop a device from having an odd number of blocks.
if the system wants to use bigger logical blocks, it is its problem
what to do with the extra block.  one of the SCSI drives i'm using
now shows 485601 as the Size of sd0disk.

you can check the value by plugging the device into some other machine
with something other than SunOS, although that might be a bad idea
if you aren't absolutely sure that system won't scribble on it.
i often check discs on our SGI machines, using the `fx' program,
but the discs are normally empty to start with.

anyhow, if you show the output for format, that might give more scope
for speculation.






             reply	other threads:[~1995-09-02 17:34 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1995-09-02 17:34 forsyth [this message]
  -- strict thread matches above, loose matches on Subject: below --
1995-09-02 13:15 presotto
1995-09-01 15:02 Steve_Kilbane

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=19950902173439.u1pAnYAH4UFwhGrh1i1S3oM6RL0NGFeweKYJLH2YjHQ@z \
    --to=forsyth@plan9.cs.york.ac.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).