Date: Sat, 3 Oct 2026 18:27:47 +0200 (CEST)
From: Jeff <pacavegano%tutamail.com@localhost>
Message-ID: <P31XDK0--J-9%tutamail.com@localhost>
| I can tell just from this that dk3 is what I want to work with.
| 769656832 104857600 4 GPT part - Linux data
| Huh. But in this output, the index of the device I want is 4.
GPT counts partitions 1 2 3 ... (no 0). NetBSD counts 0 1 2 3 ...
| So I need to remember not to use the index from this gpt command
If that is your only drive, or the only one using GPT, then the
dkN == GPT N+1 will always be true. If you ever have a different
drive, or do some unlikely manipulations to the GPT table, then
that relationship may not continue to hold.
| Okay, so I would be working with /dev/rdk3 then? Where does that 'r' come from?
In NetBSD (and in unix systems from long long ago) each block type
device has 2 interfaces, the block device, which is used for mounting
filesystems, etc, and is cached inside the kernel (all I/O passes through
kernel buffers). And the character device, which gives direct access between
application and the device as far as I/O goes (data directly moved between
the application and the device). The character device is also known as
the raw device (has no kernel assistance - all I/O needs to be in multiples
of the sector size, and be on sector boundaries - block device I/O has no
restrictions like that, applications could write 1 byte at a time if they
want, and don't care about performance). The 'r' is for the "raw" device.
All devices have a character interface, only block type devices have a
block interface, the 'r' convention only applies to block type devices
(ttys are character devices, no block device, but aren't called r-anything).
Just remember that only block devices can be mounted as filesystems,
and you almost always want to use the character (raw) device interface
for applications that want to work directly on the filesystem (fsck,
newfs, dump, ...) though those all also work (less effeciently) using
the block device.
kre