Toomas, Thank you again. Very helpful. The Z400 will only support IDE mode. ACHI+RAID is the other option which I think only works with Windows. I know it will not work with Solaris and feel fairly certain it doesn't work with Linux or *BSD either.
As pstack is not familiar to me I didn't interpret the output properly. It certainly would make good sense in a multicore world for system calls to be implemented in threads. That's a very different matter from what I assumed from the ptrace output. As the 4k sector size has been buried behind some layer of software in current drives I'm not sure how disks >2TB actually communicate the size of the disk. I'm curious and am going to try to obtain a fresh drive to determine what I clobbered. However, if the label information for the disk geometry is in the first 20K I think I can reconstruct the geometry from a dump I made of that. In any case it's an interesting technical challenge. I'm sure the format code is a mess. Old code usually is, and the last time I was asked for a disk speed was almost 30 years ago. In the intervening time I was the sole support for an aggregate of 2.5 million lines of scientific code. One especially lovely piece of work was about 400,000 lines in which the sole comment was the author's name. Fortunately, he had taken a software engineering course and chose good names for for functions and variables and I knew the science well. But he wrote about a dozen copy, paste, modify programs and I had to fix the exact same bug in many places with different names. I shall be reasonably conversant with the on disk structure of ZFS shortly as the books are due to arrive on Thursday. There clearly is a need for a "zfs unlabel <vdev>" option to remove label cruft. I ran into the problem with a 3 TB disk 7-8 years ago. On that occasion I was a bit more thoughtful and searched for the pool label and did a more surgical elimination. That was actually because the problem was the duplicate label at the end of the disk. I came along just after SMD disks had disappeared from the landscape. Reading instructions for setting those up made me very glad that they were gone. I'm fairly sure the geometry stuff I ran into was part of that process and came from BSD. Have Fun! Reg On Tuesday, March 2, 2021, 02:35:33 AM CST, Toomas Soome <tso...@me.com> wrote: For some unknown reason, your disks are recognized as PATA (IDE) disks and not SATA/AHCI. That alone is bad because IDE is slow and cmdk driver is not the fastest one either. You should start with checking out if AHCI (SATA) is available. That alone should not get to the crash but bad things happen. > Error: can't open disk '/dev/rdsk/c4d0p0'. Now this line is actual error - we do try to open whole disk device (*p0 is special device which does allow access to entire disk surface), but we fail. The bug there is obviously about this error - we failed to open the disk, we should not continue from this point, but we still do and the punishment is segmentation fault because some needed data structures are not properly set. It is not obvious why the disk open is failing there, the error code is not printed and you seem to have root rights. From this point, I’d run truss format and would seek out the failing open() to get the error code, perhaps it would explain. Yes, the code of format command is mess (I have been in it more than I would like to;), also we would need better tooling to handle disk partitioning, allowing easy scripting etc, something *like* freebsd gpart has been in my mind for a long time, but I haven't had time to think about it more… rgds, toomas _______________________________________________ openindiana-discuss mailing list openindiana-discuss@openindiana.org https://openindiana.org/mailman/listinfo/openindiana-discuss