Re: disk geometry (i386/amd64)
Date:Mon, 10 Sep 2018 17:37:53 -0700 From:Don NetBSD Message-ID: | So, I can use the 'd' partition to access the medium (after unlocking the label | portion). But, I can't count on anything else "displayed" by disklabel. And, | I can't count on even the displayed values for the d partition if something | tinkers with the in-kernel label before I get a peek at it. That's all correct. | > The raw partition allows this. | | Again, as long as nothing else tinkers with the in-kernel copy of the disklabel | before I look at it. No, regardless of that. Access to the raw partition ignores whatever is in the label, always. If not, there'd be no way to fix a badly broken label (as in, if the label said that the size of the raw partition was 0 sectors.) | > - DIOCGDISKINFO (using proplib!) | > - fall back to DIOCGDINFO if that failed | | Why would it have failed? if it were not implemented I think was the intent there. That is, so the code could work on various different versions of the system (be reasonably portable) - and possibly also because (this I am not sure about) not all drivers might implement the new method (yet). | [I also need to query the SMART structures and other disk parameters | but I can workaround that] SMART (what a name for something so simplistic) is available too. No idea how, but there are commands that get at it (and make changes) so it is clearly possible. | I want the same sort of access -- but to the disk controller. Disks are a little more more uniform and have a better structured command set than the parallel port, so it is possible that there may be some interference from the driver that simply knows that some things are possible, and others are not - even if you disagree. But just reading/writing arbitrary blocks on the drive should be possible. kre
Re: disk geometry (i386/amd64)
On 9/9/2018 10:26 PM, Michael van Elst wrote:
On Sun, Sep 09, 2018 at 05:49:15PM -0700, Don NetBSD wrote:
On 9/9/2018 1:52 PM, Michael van Elst wrote:
On Sun, Sep 09, 2018 at 12:08:14PM -0700, Don NetBSD wrote:
Said another way, are these "in-kernel" values (which no longer reflect
the physical medium) ever reported in other system calls/ioctls/etc.
INSTEAD of the "real" values?
What is 'real' ? Start with the assumption that there is no way to know
the real data and that the disklabel is the method to record such
information. 'real' is then what you wrote into the disklabel.
The disk has a real size that can be queried from the actual device.
disklabel predates that. At that time you knew the data from looking at
the device with your eyes or reading the documentation. Then you wrote
the data as disklabel to a known disk sector.
Yes. The early IDE drives required the controller to tell *them* what
their geometry was.
This didn't really change, except that something like the disklabel
tool will now get the data by querying the drive and then writing it
to the disklabel sector. Other software (mostly) gets the information
then from the disklabel.
But, the system knows the geometry (sectors + sector size) from the device
probe -- even if disklabel is never invoked. This is the data that I want
without the "system" deciding to "color" it (or alter it!) for me.
E.g., in our products, we talk directly to the drive and don't require
something else to do this on our behalf.
I wanted assurance that I could access the 'd' partition and be assured
access to the entire medium, regardless as to what MIGHT have been encountered
in the sectors of the medium that NetBSD examines in search of a label.
That is always true. If there is no disklabel on-disk, you will get a
generated one, if there is a disklabel, you will get that. But for the
raw partition the offset and size are ignored.
So, I can use the 'd' partition to access the medium (after unlocking the label
portion). But, I can't count on anything else "displayed" by disklabel. And,
I can't count on even the displayed values for the d partition if something
tinkers with the in-kernel label before I get a peek at it.
(In theory, *I* should be the only thing dealing with that disk)
-> find the raw partition with sysctl
-> just access it.
Further, I wanted to know that I could query the OS for details as to the
size of the medium (sector size and number of sectors).
on the media to have been preinitialized *or* requiring it to be "initialized"
prior to my access. (I *won't* be writing a "disklabel" onto the medium but
will be altering much/all of its contents, otherwise)
The raw partition allows this.
Again, as long as nothing else tinkers with the in-kernel copy of the disklabel
before I look at it.
I had planned on DIOCGDINFO -- with all the caveats mentioned
above. Perhaps DIOCGDISKINFO would be a better choice?
Old (but not too old) code needed to:
- DIOCGDISKINFO (using proplib!)
- fall back to DIOCGDINFO if that failed
Why would it have failed?
DISKINFO appears to not be "confused" by changes to the in-kernel label
(edit disk size, etc. using disklabel(8); verify the changes persist
beyond disklabel(8) invocations; run drvctl as a wrapper for the DISKINFO
ioctl to verify the original drive values remain intact).
I've not yet tried this with the DINFO ioctl.
(It may be easier for me to just start at the device probe and work my
way *up* into the system than to attempt to dig down from above!)
- optionally use DIOCGWEDGEINFO to support partition devices ("wedges")
No wedges. No partitions. No filesystem. Disk is just "blocks of persistent
memory". I just need to know how many, how large they are and be able to
access ALL of them -- regardless of what the disk may have "experienced"
prior to my "seeing" it.
[I also need to query the SMART structures and other disk parameters
but I can workaround that]
There's no confusion as no one/nothing looks at the disk besides my software.
The OS will look at the disk as soon as it is attached.
Only to probe it. The drive is never mounted. Never labeled. Never
"anything" -- other than the actions I will be taking (or, others staff
operating under similar constraints).
E.g., if I attached something to a "printer port" and it wasn't a printer, the
OS wouldn't care. Yet, would still let me use that hardware to talk to
said device.
I want the same sort of access -- but to the disk controller.
But, I'd be concerned about pulling a drive that was still *spinning*.
atactl(8) doesn't seem to work with sd(4) devices. I'll have to see if
drvctl -d spins the drive down as it is disconnected (and maybe a timeout
to ensure the operator doesn't remove the drive before its had a chance
to spin down sufficiently)
For sd devices you can try 'scsictl ... stop'.
Ah, OK.
I'll start digging through the sources to verify what is happening at
the physical interface in each
Re: disk geometry (i386/amd64)
On 9/10/2018 11:33 AM, Mike Pumford wrote:
On 10/09/2018 01:49, Don NetBSD wrote:
I'm not concerned with automatically detecting insertion/removal; that's
the job that the operator performs (above) -- along with the tagging of
the media, etc.
I've done a lot of work with SAS disk enclosures that support SES. They often
have an SES command that can turn off the drive in a bay prior to removal (but
support is optional).
Aren't standards *wonderful*? What value to "optional" if folks can elect to
NOT implement??
My read of the SATA spec indicated that hot plugging was part of the SATA
standard (and, by extension, SAS). But, that support for it on HBA's was
(ahem) "optional". In particular, support for cold presence detect (but, I'm
relying on the operator to perform that function as HE will be the person
doing the plugging/unplugging!)
[None of the products involved allow the drive to be removed so this wasn't
an issue for the design]
OTOH, when trying to repurpose someone ELSE's hardware, those details get
to be important (and, often hard to discern, reliably!)
But, I'd be concerned about pulling a drive that was still *spinning*.
atactl(8) doesn't seem to work with sd(4) devices. I'll have to see if
drvctl -d spins the drive down as it is disconnected (and maybe a timeout
to ensure the operator doesn't remove the drive before its had a chance
to spin down sufficiently)
A SCSI stop unit command may spin down a SAS disk but its not guaranteed as it
depends on whether or not the SAS HBA or expander is sending the drive periodic
NOTIFY primitives (which trigger drive spinup). What works with one SAS HBA may
not work with a different one.
On a more practical note. As long as you disconnect the drive from the
connector gently and give it 5-10 seconds to spin down before any significant
movement SAS/SATA drives tend to survive removal even if they are spinning.
As with most enterprises, I'm having to deal with nontechnical "political"
issues, here.
I'd first suggested using existing product (with a firmware update) to perform
these tasks. The advantages being:
- we have a virtually unlimited number of them ("build more")
- they use much less power per spindle than a repurposed server
- they can be scaled to process tens or even hundreds of concurrent drives
- eliminate all the noisey fans
- we know EVERYTHING about what's in the box (hardware & firmware)
- I can dumb-down the requirements for the operator (so he doesn't damage
a test fixture *or* components that will be used in saleable product!)
But, some bright-eyed dweeb uttered "Why not use an old server and write
something in Linux to do the job?!" -- because, to said dweeb, Linux is the
panacea for all problems technical (ignorance must be a wonderful state of
mind -- everything is "easy-peasy"!)
So, *his* "solution" fell into my lap to implement. Having no taste for Linux
(running NetBSD since 0.8), I picked a more familiar platform. I'd like to
make a "legitimate" effort to make it work. But, note that the more stuff
that I rely on in the design (e.g., the hot-pluggable HBA), the more
restricted the choice of repurposable hardware available:
"Why can't we make another one of these fixtures? We've got several
other old servers in the scrap pile..."
I don't want to have to explain how all servers are not created equally.
[Ideally, I'd like to throw it back into *his* lap and watch him struggle
to "solve" the problem -- and separately, pursue a parallel approach of
repurposing our existing product (hardware & software) to be available
when he's publicly learned his lesson (Linux is NOT a panacea). But,
that would be too petty. Given time, he'll learn that solutions are
rarely as simple as they seem!]
In SAS hotplug is not optional. ALL SAS HBAs should support it regardless of
whether the drive is directly plugged in or in some of drive carrier. I don't
know if NetBSD will deal with these events though.
I'm using a Dell 2950 as a first pass. The drive sleds don't add anything
to the mix -- the HBA can accept SATA drives as well (but no mix-n-match).
The SATA->SAS converters that would be used in a normal deployment can be
removed as they would just complicate the job performed by the "operator".
The "support" question is then one of whether NetBSD can issue the correct
commands to the drive to prepare it for removal (and make it ready after
insertion). Without the hot plug capability, the operator would have to
wait for all drives to be processed and then power down the server to replace
the drives with the next set. And, how much information I can extract from
the native drive (e.g., serial number, model, etc.)
[This is how I'd support changing drives using our own hardware -- but, we
could afford to power down ONE drive/system at a time and not impact N
other drives that happen to be sharing that repurposed server]
Re: disk geometry (i386/amd64)
On 10/09/2018 01:49, Don NetBSD wrote: I'm not concerned with automatically detecting insertion/removal; that's the job that the operator performs (above) -- along with the tagging of the media, etc. I've done a lot of work with SAS disk enclosures that support SES. They often have an SES command that can turn off the drive in a bay prior to removal (but support is optional). But, I'd be concerned about pulling a drive that was still *spinning*. atactl(8) doesn't seem to work with sd(4) devices. I'll have to see if drvctl -d spins the drive down as it is disconnected (and maybe a timeout to ensure the operator doesn't remove the drive before its had a chance to spin down sufficiently) A SCSI stop unit command may spin down a SAS disk but its not guaranteed as it depends on whether or not the SAS HBA or expander is sending the drive periodic NOTIFY primitives (which trigger drive spinup). What works with one SAS HBA may not work with a different one. On a more practical note. As long as you disconnect the drive from the connector gently and give it 5-10 seconds to spin down before any significant movement SAS/SATA drives tend to survive removal even if they are spinning. In SAS hotplug is not optional. ALL SAS HBAs should support it regardless of whether the drive is directly plugged in or in some of drive carrier. I don't know if NetBSD will deal with these events though. Mike
Re: Recommended desktop environment?
Thomas Mueller wrote in <20180909071938.644bfa7...@mail.duskware.de>: .. |I didn't know about i3-gaps but now see it in FreeBSD ports but not pkgsrc. Thing is also, you seem to have super-duper boxes whereas i am happy to have tinyc in order to develop my little MUA and not more than that until now, unfortunately. I cannot quickly generate a new XY port for port system YZ and get it going, with all the ML stuff that is involved there. --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
Re: Recommended desktop environment?
Thomas Mueller wrote in <20180908132956.6a9dea7...@mail.duskware.de>: |from Pedro Pinho: | |> Here's a complete list of WM's for *nix systems |> https://www.gilesorr.com/wm/table.html | |> What exactly do you mean with " I tried awesome some years ago, but the |> "awesome" decoration/artwork just got in the way and confused me"? |> Don't take me wrong, I would just like to know what was so confusing. |> Awesome user here ;-) | |I looked through that list of WMs web page, found i3 but not i3w. | |Steffen Nurpmeso's preferred ahwm was listed as discontinued; is also \ |not in FreeBSD ports (category x11-wm). So I might not be able to \ |try it even if I wanted. Nothing to continue in my eyes; you can always have more and iterate over the code of course. No drag'n drop, of course. But copy, that is enough for me. It used to use GNU autoconf; i have patches and last i compiled it (a few months ago) it compiled smoothly (with default CC flags). I can give you the patch if you want, just ask. --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
Re: Recommended desktop environment?
On Thu, Sep 06, 2018 at 05:01:41PM +0100, Patrick Welche wrote: > Not as fun as I had hoped! It has been a while since the last round, and I > wondered, given an ideal world with infinite developer time and full > documentation, with just an eye on correctness, what current views were on: > > * wayland vs X: what would The Right compositor look like? > > * What would the notion of a "seat" in a > > https://www.freedesktop.org/wiki/Software/systemd/multiseat/ > > sense look like in NetBSD? > > * ioctl vs sysctl: > GTK4 -> Vulkan(!) -> Mesa 18.1 -> kern/51786 how to pass info to drm The answer to the last question is "neither!" according to yesterday's commit from Taylor - thanks! Any thoughts on the other two? Cheers, Patrick
