Re: help setting up encrypted partition

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Sat, 18 Oct 2014 11:03:12 -0700
    From:        scar <scar%drigon.com@localhost>
    Message-ID:  <m1ua12$518$1%ger.gmane.org@localhost>

  | alright thanks i think i'm getting it.  was also reading the document at
  | [1] and noticed maybe i should be using just "wd1" with fdisk and
  | disklabel instead of "/dev/wd1".

Yes, or /dev/rwd1c (or d on other ports).   There is no /dev/wd1

  | the whole naming convention is
  | throwing me off, too, as i'm used to linux i guess where sda1 is the
  | first partition, sda2 is the second one, etc.

There's no real difference, each has 3 parts to its name, the initial
part, which names the kind of device (sd or wd etc), the next part which
selects which particular drive (which linux numbers a b c, and NetBSD
numbers 0 1 2 3) and the final part which selects a partition on the
drive (which linux numbers 1 2 3, and NetBSD numbers a b c d).

The NetBSD naming system is what unix has used since it was first
invented (early 1970's) - why Linux switched the letter/number around
I have no idea - but it really makes no difference.

  | whereas you might only
  | have two partitions but in NetBSD they might be called wd1a and wd1e but
  | wd1[b-d,f-h] still exist in /dev.

Thats because then entries in /dev are (on NetBSD, and currently) static,
and pretty much the same for everyone (at least in their initial setup, you
can add or remove entries however meets your needs).   So, names are put there
for anything anyone might have, not just what your system happens to use.

NetBSD is flirting with the idea of having a devfs, which would get devices
created init by the kernel to match the hardware that's actually connected,
but it isn't there yet.

  | then there is also /dev/rwd1 et. al.

Well, not /dev/rwd1 itself - those are "raw" discs.   For filesystem
capable devices there are two access methods, the raw one, where data
is transferred directly between the application and the device (which means
the application must understand the device constraints, and only do transfers
that make sense to the device - discs cannot write just one or two bytes...)
and "block" (or buffered, or cooked) access, where all data is transferred
between application and device via kernel buffering - and the kernel takes
care of reading a block (if it is not already in the kernel's buffer) replacing
the one byte the application wants to write, and then writing the block back
out again (sometime later.)   Filesystems only go on block devices, but
other applications that deal with filesystems (dump, fsck, ...) can use
either, and are usually more efficient using the raw device.

When you tell such an application an abbreviated name (like just "wd1")
it generally converts it to /dev/rwd1c (or /dev/rwd1d on other ports).
Only applications that know they're going to be dealing with discs do
this kind of thing of course, you cannot "cat wd1" (unless you have a file
of that name naturally), but you can "cat /dev/rdw1d").

  |  what can i read to understand all of this better?

Almost anything that has been written that describes unix - in some
respects, the older the better - the original BSD books (McKusick et al)
would be one good choice, but there are lots of others.   It also doesn't
need to be BSD for this - any older unix systems used the same basic
conventions.

kre