Volker A. Brandt wrote:
> Hmmm... the current scheme seems to be "subject verb <object>".
> E.g.
>
> disk list
That would work fine for me!
It would also be easy enough to put on a "rosetta stone" type reference
card.
>> [0] Including lspci and lsusb with Solaris would be a great idea --
>>
>
> Well, there is scanpci.
>
I'm embarrased to admit that scanpci hadn't lodged in my long-term
memory until now... But why is it in /usr/X11/bin/, and not in
/usr/sbin/ like the other utilities that inventory the hardware?
>> When I first learned Solaris (some years ago now), it took me a
>> surprisingly long time to get the device naming scheme and the partition
>> numbering. The naming/numbering is quite intuitive (except for that
>> part about c0t0d0s2 being the entire device[1]), but I would have felt
>> that I understood it quicker if I'd seen a nice listing that matches the
>> concept, and also had quick way to find out the name of that disk that I
>> just plugged in. My friends who are new to Solaris seem to have the
>> same problem out of the gate.
>>
>
> I did not have this experience. I came from BSD where there were
> things like /dev/sd0d (which also exist on Solaris), but the Sun
> way was not too strange...
>
/dev/c0t0d0 isn't strange. Merely unfamiliar to a Linux switcher.
There just wasn't a way to confirm that one was reading this list
correctly, at the time. And running format seemed like a dangerous
kludge, since I didn't want to /modify/ the disks at all.
>> [2] If I'm giving someone a tour of Solaris administration, /dev/sda
>> isn't particularly different from /dev/dsk/c0t0d0. But if I open
>> /dev/dsk/c0t0d0s2 with a partitioning tool, repartition, then
>> build/mount a filesystem without Something Bad happening, then my
>> spectators heads usually explode. After that, they don't believe me
>> when I tell them that they mostly understand what's going on. Yes, ZFS
>> and the EFI disklabels fix this when you have a system with a ZFS root
>> and no UFS disks -- but UFS is still necessary in a lot of
>> configuration, so this kind of system-quirk should be made obvious to
>> Unix-literate people coming from non-Solaris backgrounds.
>>
>
> Maybe it's because I have a Solaris background, but I fail to see
> any quirk here...
>
I can explain why a partition with a Solaris disklabel inside an MSDOS
partition makes sense (my apologies for sloppy use of the terminology
earlier), and I can explain why BSD uses a similar technique when
running on a system where the boot-firmware only understands MSDOS style
disklabels.... But, the s2 thing is f-ed up, conceptually speaking:
1. Calling s2 a slice makes it a subset of the device, not the whole
device. But it's the whole device.
2. The number s2 is arbitrary. If it were s0, then there would at
least be the beginning of the list. If it were s3, it would be at
the end of a 2-bit list, which could be explained historically.
If it were s7, it would be at the end of the list. But, no, it's
s2. Why?
3. None of the grey-haired Solaris gurus that I've talked to have
ever been able to explain why.
4. Can you use s2 when the disk-label is corrupted? If it's the
whole disk, maybe you can. If it's an entry in the disklabel,
maybe you can't. I seem to remember that I can write to s2 in
order to fix a borked label, but that makes no sense, and I don't
believe it. Maybe I'm loosing my mind. But, then again, my point
is that the s2 thing makes me loose my mind. :-)
Using c0t0d0 to refer to the whole device (which works in some cases,
such as zpool create) makes a lot of sense. If it's a slice, it really
should be a slice.
I just accept that the s2 thing is the way it is, and Solaris disk
management isn't difficult or mysterious... But, these kind of quirks
really did derail my learning process, and I've seen it derail the
learning process of others, too. I realize that changing a fundamental
part of the system for the sake of aesthetics would cause a lot of chaos
for little benefit... So I'm just suggesting that the normal disk tools
be changed to make this quirk obvious at a glance -- so that the
uninitiated may learn the system more easily.
-Luke
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
