Re: Use of disklabel, MBR and GPT

[mlelstv%serpens.de@localhost (Michael van Elst)]

bruce.lilly+nbsd%gmail.com@localhost (Bruce Lilly) writes:

>And therein lies a potent source of confusion, as a GPT disk doesn't
>have any citrus-y "wedges" (or "slices"), so it's unclear where such a
>"wedge name" would come from.

Just like slices are the partition model used by disklabel, wedges are
the partition model used for other schemes, in particular GPT. So the
disk obviously has wedges and the name somehow comes from GPT.

And you are right, the documentation lacks details.


>Compare e.g. to fstab on PCLinuxOS, where
>UUID=
>and
>LABEL=
>are pretty clear about what's being used.

That's why you specify NAME= and not LABEL=, i.e. the wedge name (which
can come from other partitioning schemes than GPT).

Also LABEL= and UUID= can be ambigous if you support more than one
partitioning scheme.


>> The NTFS code doesn't support writing.

>That's true for the plain "ntfs" driver, but not ntfs-3g (or ntfs_3g)
>via fuse (or PUFFS).  Works fine on all of the systems mentioned,
>but (other than MS Windows and Linux) requires a bit of finagling.
>For NetBSD in particular, the default kern.sbmax is too small for
>the default perfused/puffs/libperfuse buffer (i.e. kernel and PUFFS
>subsystem are incompatibly configured as delivered), so either
>kern.sbmax has to be increased or PERFUSE_BUFSIZE has
>to be decreased.

True, but no fuse filesystem like ntfs-3g is delivered with the
system, and IIRC you get information how to tune the system for it.

Saying that, kern.sbmax is too small for many other unrelated things.

-- 
-- 
                                Michael van Elst
Internet: mlelstv%serpens.de@localhost
                                "A potential Snark may lurk in every tree."