>b) No doubt someone has managed a), but I meant b) (Keep It Simple)

I agree with you. Just trying to get as deep as possible.


>> but I am not sure about the meaning of the "*" at the end of some records
>> (a,b, d and h)
>> Maybe indicates the partition not ending at cyl boundary?
>
>I think that is correct.


I doubled checked,  and i am more convinced it is.

> a= root      (   7.76 MB)
>> b= swap      (  32.65 MB)
>> c=           (1001    MB)
>> h= /var      ( 143    MB) .....!"h" is "sort of physically" before "d"
>> d= /var/tmp  (   7.76 MB)        or before "g" = "d"+"e"+"f"... weird?
>> e= /usr      ( 150    MB)
>> f= /home     ( 659    MB)
>> g= /home+/usr/var/tmp  (816.76MB)
>>
>> Sounds this a reasonable guess ?

>The sizes match Size*(BLOCKSIZE==512), so you read the output correctly,
>but the question is, does this make sense for your computer? Is just
>root, swap, /usr good enough? ((Or after all the crontab nonsense, better
>include /var...))

I read that in the docs but it was not clear to me where to put the users.
Under root in /home? (sesems obvious,  otherwise why is it /home there?)
or under /var/users or even /usr/users? Yes, I read that too (the unix way!
:-)

>It really is up to you how you want to use it, eg., I have a 135Mb root
>of which 31Mb are used, a 100Mb /var of which 6Mb are used, 1.6Gb of /usr
>of which 1.5Gb are used, and 397Mb of /home of which 360Mb are used. (+2
>lots of 100Mb swap)

I like the idea of having an almost full /root and /usr and minimum write
activity
on them: Only at release update time or configuration stage. It would be
good
to do the same with /usr/local and /usr/pkg but those are moving targets if
one
likes to try "new" software. Difficult to estimate sizes.

The rest goes to /var ( news and web proxy  or whatever...) and /home
(users space where all the variable things go anyway (ftp, http, usr/src
usr/pkg)
/home, samba shares, emul/, etc, etc, etc. Requires special care to plan
backup
strategies but it pays off with flexibility to play with larger sources.

I was unsure about separates /var and /var/tmp under *BSD...I'll experiment.

I wonder if usr/pkg has its own tree with libs, etc, and such below it ?
if not I should rethink the above scheme.


>> Notice that there is no offset for the a partition (no place for
>> bootblock?)
>
>The bootblocks live at the beginning of the root partition => no need
>to reserve extra space.

I have two comments on your answer:

1) The INSTALL for hp300 recommend to reserve space (1 cylinder)
for the bootblock which is 74kB. Glupp.... 1MB for only 74kb??
So I consider to use another translation than the 1001 *32*64 so to have
smaller cylinders and leave only one cylinder large enough for the boot.
Do you know how far can you go with translation of ns, nt and nc?
I read old unices had problems with boundaries at the end of cylinderes and
such,
but also read recently that that is not a problem anymore.
I am not so familiar with the internals of ufs, or the way the netbsd kernel
treats
them. (primary source beside the source code itself?)

2) Reading the source code of disklabel.c (or was it diskpart.c?)
I found that the last "x" even numbered sectors are reserved for
mapping bad blocks if possible.
 ----

Another thing that puzzles me is what NetBSd reports at boot time for this
disk:
1760 cyl, 15 heads, 2015615 blocks (512 bytes/block)
This is of course is close to the 2050048 blocks from the chs=1001 *32*64
but assuming 15 heads the resulting number of sectors per track would be
ns=32 x 64  / 15  which is not an integer... buuhhhh.

Notice the size reported is slightly larger than the 1001MB figure
above, but I read that should not matter.


>> Any ideas about pointers to the reasons behind the diskpart layout ?
>
>Maybe someone who uses your architecture has some clues?
I'll try, but since diskpart is in every architecture I tried here first.

Thanks a lot for this "conversation".
Cheers,
Lazaro