[illumos-gate] 17017 zfs: rename get_temporary_prop to zfs_get_temporary_prop -- Toomas Soome <tsoome⊙mc>

sorry if moving this here is inapropriate, are there clients of the 32 bit userspace other than virtualization? it would seem to me that because it isn't tested as much that defects could creep into 32bit userland unnoticed due to changes in regular 64 bit space that don't cause defects there

forgive me if there is already adequate regression testing to ensure this isn't an actual problem

it is always a problem

I have seen something like no problem in 32bit x86, 64-bit x86, 32-bit sparc but the bug appeared on 64-bit sparc.

tsoome, panorain left the other channel and since 32 bit support involves kernel space i thought it might better here

gcc uses 3 stage bootstrap as a form of validation, could some portion of the userspace be built in 32 bit for the same purpose? maybe not every build but like periodicly

? most of our userspace is 32-bit

oh, ok

so it's still being vigorously used

yes. and we kind of need to change that;)

there's been a _little_ bit of talk of making most of the binaries 64-bit, but not something that'd happen overnight (and for comapt we'd still need the 32-bit libraries so unbundled stuff that's 32-bit will still run)

i was thinking about ineffiuciencies because of replicated functionality being mapped to memory twice

default should change to 64 bit long before deprecation of 32 bit ideally

well, there's 13 years and 11 days left until the 32-bit userspace starts failing because ld.so.1 will get EOVERFLOW errors on every stat call trying to find libraries to load

thats good:P

somehow (because it'd be too easy :P) i'm guessing we can't just use stat64() or such there...

stat64() uses 64-bit inode & size fields, but still has 32-bit time_t fields - you would need to implement a new variant to get 64-bit time_t fields, like the large time API some Linuxes have provided

sourceware.org/glibc/wiki/Y2038ProofnessDesign for example

Howdy I'm using OmniOs and some combination of mashing ^c and ^l ends up bricking my cursor and I can't see what I'm typing. Any ideas what key combination is doing this?

does ^q fix it?;)

or echo ^o^q

^q did not fix

even like, echo ^v^q ?

the echo commands arent doing anything either

to clarify I am inputting text, the term just isn't displaying my inputs

relogging works, just wondering if anyone had run into this before

Guest39: in Linux I've had it sometimes where the terminal has got messed up and things don't work as expected (display of what's being typed, scrolling etc) in that case the `reset` command at the shell terminal often resets things back to normal - I'm not sure if that's similar to what you're seeing or not and a possible fix

fortunately, you've got nearly 8000 years left to fix illumos.org/opensolaris/bugdb/bug.html#!4178551

→ OpenSolaris issue 4178551: ctime() has 64-bit year-10000 bug (Defer)

(Defer)

really should just obsolete ctime() before that and convert callers to strftime() instead

alright, I feel sufficiently dumb as I've never had to do this before. How do I partition a disk in 2 on illumos with an EFI label?

every piece of documentation I've looked at starts conflating things with slices. As far as I understand with EFI/GPT, slices are non-overlapping

I just want to carve out ~20 GB from the front and allocate the rest to another partition

format -e should allow you to specify EFI

slices on a GPT disk are just partition entries

yes but then it assumes one single EFI partition, I'm trying to subdivide the disk

though there's some mapping of type (sys, usr, etc) to well known GUID types

you would subdivide the disk

yeah, I found the "fdisk" lets me delete and create just one single partition

I tried the "partition" option, and that won't let me "tag" the partition with an arbitrary name, not that that's important, but it defaults to "usr"

richlowe: step one, draw two circles, step two, draw the rest of the owl? What am I missing here?

what are the "tags"? I've not seen this notion in other UNIXes. FreeBSD has GPT labels, which I assume would be the same thing, but you can arbitrarily name those. You seemingly cannot with the "partition" option from the format command

it's the partition type

in the older SMI disk label format, you had unassigned, boot, root, swap, usr, backup, stand, var, home and a few others

for a GPT disk, those get translated to well known GUIDs

ok, so for a disk that is getting split to go into a zpool, what tag do I assign to both of these?

I assume it basically doesn't matter?

the zpool command uses usr

so that should be fine

you're going to pass the slice in if you don't want it to use the whole disk anyway

you may want to leave the reserved partition that gets created by default as well

gotcha, so I'll basically ignore the p# at the end of the device string

if it's going to be used by illumos

KungFuJesus: sorry, I stepped away. jbk has you covered, there's no separation with EFI/GPT like there used to be

IIRC, the p# ones are for legacy MBR labeled disks

on x86

alright, so, right now when I "label" the GPT disk, it just creates one mega "EFI" partition. I assume the "reserved" one is the ESP partition as it's known on other platforms?

no

it's used by the kernel to store some metadata about the disk in certain circumstances

ah, so something akin to zpool's cache when it "tastes" the drives?

kinda -- basically it wants to try to create a unique identifier for the disk

ah, so that's probably the GUID being stored that ZFS uses?

reserved is used to store fabricated disk ID in case the disk does not provide one.

no that's different :) I think this might predate GPT partitions

I see, I always assumed that was something that was more or less baked into the GPT table in some fashion, but maybe FreeBSD has always simplfied this for me with geom

I mean at the moment, after labeling the disk, the "fdisk" menu just shows me one partition

but yes, if it can't generate a unique id (I think normally it tries to use the WWN of the disk if it has one -- either via scsi inquiry or for SATA it's sometimes buried in the identifying info that gets returned)

oh, "reserved" is at the end

does this have anything to do with GPT's "backup" table?

GPT disk labels to get a unique GUID on them, though if you relabel them, it can generate a new GUID

no

just I'm guessing it's normally just put at the end of the usable LBA range just to try to keep it out of the way

(so the backup GPT label is usually right after it)

ah ok, so this is just a special solaris thing

yes

man, I didn't think it'd be fundamentally this different from BSD given their quasi shared lineage with a distant cousin UFS

i think a lot of the confusion comes with how partitioning was originally done on x86

what are the permission flags? Are the defaults wm fine?

yes, those I think are ignored for GPT

basically on sparc, the legacy (SMI) label supported 8 slices (partitions), each partition had a 1 byte tag (type) which was more of a hint than anything (no place to put a description in UFS, so if you had 4 slices with UFS filesystems on it, it gave you an idea what was what)

and the slices could overlap, so convention was s2 would be a slice that represented the whole disk -- so you could read/write that to backup the disk

when x86 came around, instead of using that on a disk

the first problem is that no BIOS out there would understand it

they only understood MBR partitions

so an issue for your boot disk

so instead, they would take an MBR partition, give it a 'solaris' partition type

and I definitely want to address these by slice, not the p#? Or does it not actually matter?

and then write the SMI label at the part of the partition and subdivide that MBR partition into slices

which is why on x86 you get the p# entries

however once GPT came around

the whole p# wasn't really needed anymore

(for compatability, most things -- not just illumos -- will still write a 'protective' MBR partition table out)

where there's 1 MBR partition (of type UEFI)

but that can pretty much be ignored

I mean to be fair, the 4th based loaders didn't need to make slices overlappable. Making 2 the whole disk was also seemingly a bizarre choice

so you want to use the slice devices

as those will map to the GPT partition entries

ok, so instead of the protective MBRs, which are probably using a layer of glue somewhere

I don't know if there'd be any unexpected issues, but it seems like we could probably stop creating (at least by default) the p# entries on GPT disks since they are kinda confusing

you mean device nodes? that is not bad idea

now my understanding of l2arc_noprefetch, setting this to 0 with mdb doesn't do anything until you reimport the pool?

or, would simple setting this to 0 be enough for prefetched things to land in l2arc from an already imported pool?

simply*

(I did set it in /etc/system, I'm just trying to avoid a reboot)

i think it'll take effect immediately (though won't impact any l2arc data that's already been prefetched -- i.e. changing it won't evict anything exiting)

ok, but it'll probably hit the cache the second time around after it's flushed out. Awesome

you would probably like this one too: openzfs/zfs 043c6ee

I figured I did see l2arc_noprefetch somewhere...

KungFuJesus: You basically never want the fdisk(8) command, or the "fdisk" menu in format(8), unless you're looking to create an old fashioned vtoc-style partition (the SOLARIS2 type) inside an old fashioned MBR-only disk

and yes, always the slice (s*) devices

unless you need the "whole disk" device, which is p0