OpenZFS Leadership, 3 Mar 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: March 2021 OpenZFS Leadership Meeting

Description

At this month's meeting we discussed: vdev properties; zpool import; code cleanup.

meeting notes: https://docs.google.com/document/d/1w2jv2XVYFmBVvG1EGf-9A5HBVsjAYoLIFZAnWHhV-BM/edit

A

All right, let's get started with the uh first uh march 2021 open, zfs leadership meeting uh because of the way the month falls. We'll have our another meeting four weeks from today, which will be also in march.

A

um There's not too much on the agenda for today. uh So there'll be time for q, a or other discussions um I got and uh brian. Do you wanna just mention um that we're still working on the release, numbering planning, stuff.

B

Yeah, um I don't have a concrete proposal for today, um so nothing much to share there. um That's about.

A

It all right so we'll aim to get that together for next uh next meeting um and the other. uh The other thing they've been the agenda is um I asked alan to share some more about the v dev properties work that he had done. um I thought that it was years and years ago, but then I saw you know it was only 2019.

A

The 2019 um development.

B

Years ago it was about.

A

30 years ago, at this point, matt yeah, it sure feels like it. Doesn't it well.

C

I I think I first presented it in 2018.

D

C

Or maybe the idea or something but uh yeah, we spent a bunch of time on it at the 2018 hackathon and then so. In 2019 I presented what I'd come up with, based on that, okay.

A

C

There's been a couple members.

A

um So uh I think we mentioned this a couple of meetings ago, but uh mark maybe is going to be working on the um like v dev, no alec stuff, um that we need for our product and um we were basically we wanted to figure out what the user interface for that should look like, and it seemed like if we could make it so that the user interface was the same as kind of the grand plan for v2 properties.

A

Then that would be nice.

A

um So uh I wanted to have a discussion about what that user interface would look like, um and then I was also kind of curious on like where, where the code is at and if you know if it would make sense to complete that the real video properties in the short term um versus if we should like make something that has the same user interface for the one thing that we care about and then we can kind of refit it back into the infrastructure.

A

You know when, um when, when the whole thing lands.

C

Yeah, um I think it's I'll give it another once over tonight, but I'll be able to push a pull request for it uh this week, so that people.

D

C

And hopefully that means that it can go that way um because yeah one of the things that drove me to the idea of doing this v dev properties was actually talking with matt about this cued v-dev removal thing at the the zfs user conference at dotto in what was that 2017? Was it oh.

A

Gosh we've been working on, we've had that on the plans for so long yeah, uh and that was one of.

C

The ideas- and then I I know um it was uh richard- was uh put some comments on the slideshow based on the mailing list post earlier this week about also using it, for if you have something like a metro setup where you have mirrors, but some of the disks are actually remote being able to express you know you should bias towards reading from the local mirror and he had a better way of doing it than I had thought up and that he put in the comments that I'd like to look at too so yeah as it exists right now.

C

It's mostly uh read-only properties that it exposes a bunch of stuff from vwt that are just counters and so on kind of, like the pers dataset counter case stats that we exposed not that long ago, on that I ported the freebsd, but those on a per v dev level, which is also somewhat interesting, especially if you have mirrors seeing you know how much more work is one of these mirrors doing than the other or and so on, uh but it does have.

C

uh It takes advantage of the per video zap that the device removal code added to be able to track its status and so on to be able to store stuff. So you can have comments and I created user properties, so you can put whatever arbitrary information you want about vdev on the v dev.

C

One of the ideas we had talked about at a freebies developer summit was um kind of our version of the the zed tool, um the event daemon being able to apply a partitioning scheme to a replacement disk before starting the zpool replace or whatever.

C

So you know if the original disk is partitioned this way, if we store that information in a vdf property, then when we go to replace that disk, we can apply the same things to the new disk uh and, or you know one of my pet peeves is always I want to know the serial number of the disc. That's not there anymore.

C

I can know the serial number of every other disc in the pool because it's there, but I want to know the one that's gone so that when the person at in front of the rack pulls out a disk, they can verify that that was the right, serial number uh and so on. And so.

A

C

I created this.

A

Yeah, those are all some like good use cases.

C

Yeah- and I you know any settings that made sense there- it made sense to try to hook them up to be the same way. You set settings anywhere else in zfs, which you know is zfs, set whatever or z pool set whatever. um Originally I had tried a couple of different syntaxes like originally. It was z, pool, set property at v dev, uh then the pool name or whatever, um but after playing a bit with the stuff zdfs and linux, had done to be able to disambiguate pool names and v-dev names on the command line.

C

It made more sense to just use that, and so the current form is z, pool, set property, equals value, the name of the pool and then the name of the v dev, and that allows you to set a property on a specific v dev and then on a get. You can specify multiple v devs if you want, or the keyword all and get that property from that list of v devs or all of them. Can't you supply multiple v days on the set.

C

um I don't know if I allowed that, but it could. If, if that makes sense, uh then yeah, you know, it probably does make sense, because you want to atomically set that on a bunch of them at once,.

E

And it was not it's not say, atomic or even just a convenience that says all right: yeah.

C

E

Set this this value across all mine, you guys are all these. This set of v-divs right.

C

E

The the no alec you want to say I want to actually remove five drives, so I'm gonna go now. No, I, like all five of those drives at once,.

C

A

Yeah, um I think that this pretty much makes sense. um My one one idea that I had was um you know when you're doing like z, pool set, there's there's a lot of positional parameters there right, so you have like sequel set.

A

You know, uh property.

D

A

Pool v dev, um which is which is more than we typically have um so I was thinking about um how this works for uh like data set properties, so there you have basically like zfs, set property equals value, pool slash data set.

A

So I was thinking of like a and if you, um if you want to set it on multiple things, uh you know multiple data sets. Then you, then you have to do like pool slash data set to pool slash data set three et cetera, et cetera, and the pool name gets repeated there and we have checks to make sure that they're all the pool name is the same every time.

A

So I was thinking that, like by kind of similarity to that, we could um have a way to specify to fully specify the v dev with one like word, um by doing like pool colon v dev or like something like that, like using some other special character to combine the pool name and the video name together. Just like we have pool slash and then data set name yeah, um which would uh maybe make it like a little bit. Syntactically nicer. I think it's yeah. It's definitely arguably.

C

Either way the.

A

C

It is now was just because it was convenient to steal it from z, pool iostat yeah.

E

It makes some sense I mean you have to be careful, though, because you, you have limited characters you can choose to as a separator between the pool, name, yeah.

C

E

C

Option would be like zpool v dev set as one as a new command.

C

um Well, you still end up with the same number of positional arguments. If yeah that way,.

A

Yeah and at least with um zfs you most people don't know this. I always forget this, but you can actually omit the set keyword, so you can do like zfs compress equals on pool slash, fs um and- and so you know. Presumably we could allow that here as well. I mean, regardless in either syntax. You could do z-full, no alec equals on pool colon v, dev or pool space v dev, which does make it a little bit more palatable right um but yeah.

A

I was curious what folks thought about trying to combine them into one token. um Obviously we haven't done that before so, like you know, say: z, full offline, it's like zoupol offline pool space, v dev, um and you know we we could like change that to also accept the new syntax if we wanted, like z, full offline pool, colon v, dev or or whatever other separator.

A

Folks like, I think the.

C

The part that feels weird about repeating the pool name is you can't specify a vita from a second pool in that command. Yeah.

A

This is slightly redundant.

C

A

For sure it definitely is, I mean it's the same way with the zfs command.

E

A

C

E

A trade-off, I think you know, with the common use case, which is what matt and I were discussing the company's case. It just could be a single v dab, and so it's a it's a simplification. It's all matrix. You don't have to you know it's not non-positional now, but you're right in the less common case. What is multiple b? Does now it's more verbose, because you have to have that full name in every instance.

A

Yeah- and I think the same kind of thing applies to the zfs command- it's just that we kind of we we bit the bullet very early on of like combining the pool name with the data set name um as a concept, and that seems to have turned out pretty well. There.

C

A

C

You know with set of a set, you also benefit from the inheritance and usually don't have to set.

A

C

Same property on a whole list of things.

A

Yeah yeah you can, but you often don't have.

F

A

Same with like creating snapshots, for example, where, like you, can list a whole bunch of full snapshots names, but you can do the recursive snapshot.

C

I definitely see the advantage to doing your way because it also decreases the chance of someone accidentally ending up trying to set something on the pool when they actually meant the v devs yeah.

A

C

Of disambiguates the two syntaxes a bit more.

A

Yeah, like you, don't have to worry about transposing the arguments. Yeah.

C

A

C

B

Effect, I would just add that there's a little bit of precedence for a lot of the others, equal commands of listing all the individual disks, like a lot of them, accept that now on linux, where you can give it pool and then like an arbitrary number of disks after it like z-pool list. I think.

C

B

I reused that, because it was nice.

C

B

A lot of machinery for that at the moment, so I'm a big fan of consistency, so I mean intuitively that's what I would go to what I would expect to work very, like z, zoo pool offline.

A

Pool list of discs, yeah, right and so and and from from that point of view, like keeping that insane like zoop will set prop equals value. Pool list of disks um is more consistent with that.

C

Yeah! Writing that fits in z, pool list, uh z, iostat and a couple other things use it.

G

People add, I mean there's yeah.

C

D

Much all commands yeah.

G

It is set would kind of be the oddball. If we went to this, I think my opinion is like. If we go to some kind of you know special character, then maybe we do need to think about.

G

Like I mean, I think that, like inheritance becomes an interesting thing in in the set command, um you know if you can actually do this on devices at you know like identify a top level and then have it do that for all the lease underneath it um I I I guess I I don't see a whole heck of a lot of value to adding this so that we don't have the positional nature of it given where it is in all the other commands would be. My only comment, all right.

A

Yeah I mean, I think, especially if folks don't see value in um kind of reusing that pool colon vdev in other.

C

Places the advantage.

A

To having a generalized and standardized syntax for specifying the v devs in a pool that one of yourself would be useful for other cases, yeah what other cases do you think it'd be useful for any time you want to specify a pool, a a v dev if you want to offline it, if you want to check the status of just that having a standardized syntax uh strikes me as a useful thing to go into.

C

Yeah, basically the linux one is there, but you know if we want to change it, we can yeah.

B

I think we just probably gotta.

C

Keep supporting the linux one anyway, but and.

A

Like you pointed.

C

Out it's the same as z-pool ads, equal, create and so on.

E

B

Mean all of the z-pool commands are like that: z-pool initialize, equal trim. I mean yeah kind of the convention in all of the cli commands at the moment, so I I'm not sure I'm against having a new one, but if we were to do that, I think we'd also want to apply it to all the zfs commands right. Yeah.

A

Yeah to let them take the pool, cooling device, type type.

C

Additional or modification of the I forget what the function is called, but it figures out if the list of tokens is a list of pool names or a list of a pool and then v divs.

G

I think if we came up with a new naming convention, we may also want to make it so that the v devs are self-describing, um because we have like cases where, like you want to identify it as a log or it's a mirror or you know so, would you want to have like mirror space pool colon v, dev pool colon v dev I mean like.

G

um I think we may want to think about that too. If we're looking at a new naming convention.

B

You're talking about for.

A

Zip will add yeah for depool. Add yeah, I mean well with zip, will add. um I think that you would keep that the same, because when you're, when you're, you aren't specifying a v dev within a pool you're.

B

D

A

To add to the pool right right so like, for example, um when you add a new mirror, you're doing like add, pool mirror device device, but what about like attached right right so like when you attach, when you specify the device that you are attaching to?

A

You could specify that using the pool coolant device, so it could be like attach pool colon, mirror dash one and then the thing that you're attaching to that, which is a device not a v dev right. Does that matter.

E

The difference between.

A

Attach and add would be much clearer.

C

I think that would save people a couple of foot guns.

A

A

Because, like the way that you can specify vdev like for exa, I think what I was trying to make clear there is that the a v dev like is part of a top level v. That has a name. That's like mirror dash, one or raid z, one dash zero. Where has it like dash v, divided d and that's how you specify the top level v div, but when you're like adding a a new top level v dev, you don't know what the number is right, the the cfs decides.

A

What the number is, you don't specify it. It gets.

E

Chosen for you.

A

Yeah um yeah, I mean it's a relatively minor point but- um and I still definitely see like maybe like just go just be consistent with the existing way, even if it's like, maybe not the best, you know thing that we ever came up with um and and and just do like z full set.

A

um You know prop equals value, space pool space device.

E

I think yeah, I think you know, there's enough, there's enough precedent in the other command to say that should be supported, whether it's the ideal way or not, and then I think orthogonally. I think there is some potentially future thought and something we could do in terms of saying all right. Let's come up with a naming convention which would apply across all the the full commands command's only one named vidas and these these commands or something.

G

Is there anything that we would so if we had a new naming convention it does that make things easier for things like d-raid, I mean that kind of has like a new naming.

E

Obviously d-rate is is kind of special, because it's and there's already some you know when you name the d-ray name v-dev name is- is fairly complicated because it includes.

G

E

Information and encoded within that kind of thing.

G

Yeah and it's also using like the colon right um for some of its oh yeah description, yeah.

E

Yeah you can't yeah colon is actually a bad character. You choose for the separator.

G

All right: well, I think it's a good thought exercise for sure um and see if there's something that we can improve on.

A

Yeah, um well I mean I'm, I'm fine with sticking with the syntax that allen outlined there um and I just stole what what brian.

C

Was already doing because it was, it was nice and convenient, and I liked the syntax, but you know I.

D

Definitely see.

C

Pool at vidaver, whatever you know, colon sounded good but, like you said, d-raid probably makes it complicated. uh I can see a bunch of places where that'd be useful, uh but at the same time it also a bunch of places where it'd be slightly redundant, have to put the pool name six times on the command line.

C

But you know in particular I think the one brian did for zepal iostat specifically can handle you know, pool, pool, pool or pool vita, vita pool or something and- and we don't always want the user to be able to be that uh ambiguous to us.

A

Yeah, and only probably most other cases, you want them to all be in the same pool. It's like just one pool and then like in the case of set zero or more v-dubs right.

C

All right well.

A

It's not particular.

C

I guess for set when you're doing vw properties, it would be a list of all v devs with the separator, and so you wouldn't have the pool name by itself on the command line right your z-pool set. You know no alec google's on pool at v, dev one pool at vdf2 and never specified just the pool name, and that would make the syntax more different than setting a pool property to make it less confusing.

A

Yeah, that's true.

C

Yeah, I'm not 100 sold by if it's a good idea to overload default, set to both be able to set pool properties and v dev properties. I did it because I didn't want to duplicate all the machinery of z, pool set and get and list, but.

A

Yeah, because you could imagine like if you do z, pool set some v, dev property equals value, just the pool and leave off the v dubs then it's like is that an error? Does it mean set it on all of the v devs.

C

Currently, it's an error, uh it'll say.

A

You know there.

C

Is no property called that for a pool? Okay, I think the only one that overlaps is comment uh is the only pool property that has a corresponding view of property, uh the syntax to set it on all the v devs is to use the v dev called all I see uh I gained stuff, okay,.

A

C

The iostat stuff.

A

Gotcha, so if you wanted to set on all of them, you would do set property equals value, pool all yeah, which is like a little bit. um Yeah.

C

A

C

Comes from uh is that it's awfully close to setting just the pool property uh so but.

A

Let's see what.

C

Other people think.

A

I mean there may not be a lot of overlap like do. You ever really need to set it on all of them.

C

B

I mean if you're you're sitting on all of them all it feels like it should be a pool property right. It should be encoded, someplace else right.

A

I mean the only things I could imagine that you might want to set on all are like things that you can't do nowadays like set like change. My preferred day shift, which you know is not a thing now, but I think george has a also many years old prototype for or user data, such as the vid was added on such and such date, or modified on such and such date.

A

Yeah giving you and all there is a bit of a foot cannon as well, then.

A

G

So unix way so.

A

Yeah, but I mean well, I think the true next way would be would be would be that there is not an all, but you can do like dollar paren. You know, z, pool.

F

List devices whatever- yes, yes, that's what it should be. It.

B

A

Be get rid of all everywhere.

C

Yeah it'll be uh what z pool list capital h, dash o name.

A

C

We're just important.

B

I don't think that's.

C

It see how much.

B

C

There is a way to list.

C

And it will give you just the names of the videos, that's cool and although I think that will include mirror dash one and mirrored.

A

C

A

You could, but you could probably like kind of pack, that up to get like your name, comma type and then and then like only things that are type disk or whatever leaf or whatever yeah yeah um all right. Well, I think this is a great idea.

A

um I am I'm okay with the syntax that alan originally proposed, uh I'm okay with getting rid of all, um but uh it's great that you're so far along that you'll be able to open a pr soon and then maybe mark. Can you take a look at it and help you get that across the finish line? If you need some more, if you need some more work um because yeah.

C

Mostly, I think it would just be adding the the no alec to the the property enum and then you know on set dealing with whatever we have to do to to do that. Yeah there's, definitely a bunch.

A

Of subtle stuff there that mark has investigated.

E

C

Yeah because I figured uh when I thought about it, I was like well, you gotta, you know, make that free space probably disappear from the available free space and who knows what else yep, because I had also thought about trying to do read-only, but I don't think that makes sense on a privitive basis.

A

Yeah I mean that's why this that's? Why we call this thing: no alec.

B

Rather than read-only, because.

A

We aren't like prohibiting rights, we're still going to write uber blocks there if you've done an allocation already like for a log block. You know the tail of a log block, then it's fine. You can go and write that it's just prohibiting.

A

C

But it's very similar to read only uh because the other use case we had thought of was there might be stuff in the special v dev type, where it made sense to have a v dev level setting rather than a data set setting like this ssd is just for dedupe table and nothing else like.

A

Currently, able to change.

C

Special v devs, then it would use both right.

A

Yeah, uh well, I think that you can.

A

I think, that there's special and d-dupe or.

D

Are two different types.

A

But you could imagine using the properties to change the types after the fact um I mean it probably wouldn't be super trivial, but I think you could do it by saying, like you know, set class equals normal special log, et cetera.

C

Yeah, I think the only thing the pr will be missing is that I've not written any tests for it. Yet.

C

Okay, but uh it'll, be good enough for mark to take a look at and and see if it's gonna make sense for what he wants to do, and you know.

C

I wrote it a couple years ago and have you know revised it a number of times in spurts of activity.

A

Yeah well maybe now now we have like a real use case that can help us to um get it across the finish line right.

E

C

Yeah, for me, uh the main use case was the the stats stuff I wanted. You know like the purvey, dev stat or per data set stats that we've got in the meantime. I wanted that on a per disk level- and you know I.

E

Think in the slides.

C

I also talked about there might be some level of those where we'd want to be able to persist. Those counters, maybe something similar to the the way the persistent l2 arc. Does it, where you know only every gig of rights to the v dev or something do we update the stats, but uh you know having.

D

C

Keep track of some stats persistently might be interesting too.

A

Yeah, I think you could surely persist those every txg, but uh it's just a matter of doing the work right.

A

The same kind of goes for the error counts and stuff which, which probably falls into the same stats that you're talking about. But brian you mentioned that recently, how like sometimes people get tripped up, because the error counts are in memory only and um have a bunch of weird things about them.

B

Yeah, that's something we see on the tracker. Quite frequently is people see air accounts and then they export and re-import the pool loop they're all gone right so.

D

A

Had a lot of healthy now.

B

Yeah, so that's that's! Maybe a little unintuitive.

C

That's a another, you know pet peeve of mine that we might need to look at at some point, is uh both zipl, clear and like import with the force flag uh are generally often very broad like when you do clear it does it it's like a zoople clear is what you're supposed to do?

C

If you know your jbod disconnects and you reconnect and it it's kind of somewhat similar to z, pool reopen, but it gets everything unsuspends the pool and gets it all running again, uh but you know sometimes you want to do one of the side effects of z pool clear, but not all of them like I want to reset the counters without doing this, or I want to you, know, get the pool working again, but not reset the error counters, and you know like same for zpool import dash, f, the dash f overrides, I think six or eight different safety belts, and sometimes I feel like you should be able to do force equals.

C

You know just ignore the grid uh rather than you know. Also, do this, or you know, z, pool, add ignore that the size is different or ignore that this used to be part of a different pool, but don't ignore the rest of those safety pills.

A

C

D

A

Those are all good ideas.

D

Yeah, maybe with regards to that there is this uh z pool import policy is tracked, and I think it's like somebody threw it in there for metadata validation, count or something, and as far as I can tell the only uh code that instantiates that struct is the pull main and it sets some default values. Is there anyone actually like using that struct from somewhere else and setting other values, then the defaults?

D

Do you know of any any software system that uses that is.

A

It is it not used by the um import, dash, fx, stuff capital, f, capital x,.

A

C

Extreme rewind, I.

G

Thought it was and.

D

I think extreme remind extremely rain said that, but I was talking specifically about the metadata error. Account thing, maybe.

G

D

Subfield, it's been a while, since I've looked.

G

D

That the one that's in the.

G

In the verify logic,.

A

Yeah, I think that.

G

A

Used by the verify logic, I don't know if anything sets that from user land, maybe anyway, but.

D

I was driving, it would be cool if, if we had one struct that we can maybe represent as json or some other form of structured data, and then we can just pass that to the pool import, then put it in an nv list, pass it to the kernel and then uh do it that way. Instead of yeah, I don't know inventing some complicated command line flags for every single thing of that.

A

Yeah definitely having a richer way of expressing that using like the import flags or whatever um would be nice, I mean importing is uh like one of the most complicated things there's like so much stuff going on there um and it's it's really hard to follow. Pavel did a whole lot of work on that. um You know several years back when he added like all the debug statements and all that kind of stuff, but uh it's not especially this is admin friendly, is pretty cool too.

D

Sorry ellen, oh okay, yeah. I thought it like I'm working on on that part of the code too, and I thought it would be really neat to uh have some interface to like return. All the debug statements to user space as a summary, instead of like requiring the.

A

D

Yeah and that in my mind, it's just collecting a big nv list and sending it to user space at the end of import, no matter whether it fails yeah.

A

Succeeded: it's like it's not that hard, especially yeah since, like you, don't even have to do crazy things. Like I mean crazy, you don't even have to do all that much work um because you can it's all associated with the spotty you can just like. Have the spotty have like a you know, a giant string which is, or you know, an array of strings, a list of strings that are the debug statements that we accumulated.

A

While we were importing it send those back to users land at the end um would really not be that hard um compared to like the more like general case of like I'm doing some arbitrary ioctal, and I want to accumulate all the messages from all the layers for that it's like, then, you gotta like pass down your message. Buff, you know down everywhere and let everybody like append to it, and you know you have to change the function, signature of a lot of different places versus with this. It's like we're importing.

A

If we're importing this pool, it's the only thing we're doing to this pool. So all log statements are relevant to um what you're trying to do.

B

I think that would actually be really useful because that's always frustrating when you can't import your pool. You get a really generic error message back. It's yeah.

A

I think, as a first pass like, like, you really could just say, take all those all those debug messages um that are in the import path, that pavel added and then um just have them also append something into the spot sheet uh and then like package that up into an envy list and return it back to userland.

A

That sounds like a great hackathon project.

C

The one I was going to mention is, I think, during a recovery some months ago now we came across that if you disable the spa verify or whatever tunable while an import is running, it actually skips the verify, but it stays inside the loop moving over every object in the pool and doesn't break out of the loop, uh and so it does. It saves you some time, but not the amount of time you're hoping to actually get the import to happen.

C

uh You know when you're doing a rewind, and I meant to get back to fixing that, but you know I think, there's some comments on the uh an old bug report. I don't think there's even a pull request for it uh that I know brian and I and some other people talked about it when it happened, uh but I never got back to it.

A

C

A

A great um one or two line exactly.

B

Yeah, it might be worth revisiting those defaults to for import, because I think right now the defaults are check everything right. If you go back, you far check every data block check every bit of metadata and it can take if.

E

You do extremely.

A

Amount of time.

B

A

But yeah, but I mean extreme rewind, is like.

C

You yeah you're.

B

Gonna be in a bad state right like that played, but.

C

B

C

B

C

It's like, if it's going to take two weeks to finish the import, because you have to read all you know: 300 terabytes, then you know.

D

C

Worth doing the import- or you know you do an import, read-only, extreme rewind or whatever and do a scrub, and if, if it doesn't start blowing up right away, then good enough ship it, which is what we end up doing, is restarting and trying again with the variables off.

C

But uh I guess the other thing I found in my get tree while uh digging up this vita property stuff uh yesterday was, I have pool user properties, so you can just set arbitrary user properties on the pool that one, I think, turns out to be like this big of a patch. Is that interesting to anyone? I think I wrote it originally for paul dilidek needed it for something and I to ended up in a weekend.

D

Did they show up as cfs properties like I? I think there is some confusion, because you can also set cfs properties on the like cfs data set. You can.

C

Set it on the root, but then it's inherited by every data set, whereas a pool property only.

D

C

Z pool again, okay.

D

Which is it's distinct? Okay, yeah.

C

It's distinct uh because yeah I didn't want this property I'm trying to set on the pool to show up on every data set in the entire pool, which is what happens if you set our user property on the root of the pool.

C

The root data set.

C

But does anybody have a use for user properties on a pool.

B

I don't know that I have a real use case for it, but it does kind of feel like an omission that is there for data sets, but not rules, but I don't really have a use case for it. So.

F

um We kind of had one, although we're just doing uh user properties on the root data set instead with um how we deal with managing the keys um for a z pool, because, um because also we, when we uh use eve, cool encryption, we're doing the whole pool, because we do a lot of snapshotting and cloning and trying to manage. That would be tricky.

F

So if that would have been uh nice for some things with that, as well as there's a couple other little bits where it would have been nice to be able to set like user property for cool.

F

It's also like we have on most the systems that we quote unquote support, there's one pool with all the storage, but sometimes people will try to do multiple pools to do things and so to be able to identify, as well as there's some historical stuff where the main pool doesn't always have a set name so being able to identify. Okay, which pool is actually the main pool that has all the stuff that we're looking for um we'd. Be able to do that with a user property would would be useful, though there are ways around it.

A

Yeah, I guess today you know you can shoehorn it into the comment. The pool comment, property or you can use the user property on the topmost file system and kind of deal with the clutter that that causes further down. But yeah I mean seems like a nice thing. Yep uh there might not be a ton of use cases, but if it's just a little bit of code, then sounds good to me.

C

Yeah, it would help me in a couple places.

A

Cool um other folks, other things that folks would like to discuss.

D

I just added a thing to the agenda: it's just a quick call for help, because I fear that this will get stuck. Otherwise.

D

um I've started factoring out all these, like the the platform, independent parts of zebra, write, discard and read into common code, and one thing I sum it across is the zivol geom bio strategy, which is in the freebc specific bits which, like doesn't seem so easily so easy to factor out, because it doesn't use cfs uio t yet, and the question is somebody familiar with freebsd could add support for converting a struct bio from the free bc corner into the zfs uiot, and I won't be able to do that, um and I don't know if there is any desire on the free bc site to do it.

D

And if there is anybody interested in that please step up. I posted a link in the agenda.

A

uh Feel free to bring me in slack and we'll discuss further good.

D

A

Cool that that cleanup looked really nice so far,.

D

And there are some interesting like small semantic bits which I think are just code drift over time, but could not be, and in some places I'm I'm just don't sure what the desired semantics are so yeah. Somebody during the pr review has to give that a hard look, so that there are no uh like semantical breaks between the platforms, but I think yeah.

E

D

If they are, they shouldn't be there uh under a unified codebase, but anyways.

A

Yeah um I I agree, and I think I clarified a couple of those that you'd asked about.

A

Cool what else do folks have to talk.

A

A

All right, if we don't.

D

Have anything else.

A

Then our next meeting is going to be at the earlier time nine o'clock pacific on uh march 30th four weeks from today, um looks like the calendar. um Invite time needs to be changed, but I'll ask karen to take care of that thanks.

D

A

For your input next time, hopefully we'll have an update from brian on the versioning scheme. I'd also, I'm also hoping to have an update on our thoughts on the next open zfs conference.

A

uh Which which which will be uh in the fall? But you know we we're trying to figure out like the logistics.

C

So I had a question. I don't know uh if it's been fixed, yet I don't know that I've tried to build in the last week or so, but the compatibility.d directory sim links cause problems. If you do a second make install after it's already been done. Is that somebody looking at that or fixed already that got fixed okay.

B

Someone jumped on that and fixed it for us, but yeah.

A

Yeah I stumbled across that as well. Yeah.

C

I'm glad that competitive stuff got done, though, because you know I was big yeah.

E

C

Up with the idea like was that I know, and.

A

Yeah another part super long time coming I mean, I think, that one one thing that sometimes is frustrating about um my work on zfs and the communities work on zfs in general is like we have so many good ideas that, like they feel like they're, so like it's not that hard, we just got to get it done, it'll be so great, and then you know it takes years and years years and years later, it's still not done. Yet we talk about it again. Another open cfs summit.

A

You know the next year um so that that can be frustrating sometimes. But then I think about the fact that, like you know, actually like a lot of those good ideas, have gotten done eventually.

C

Yeah, like device removal, eater, zero d raid, said standard yeah.

A

Those are a lot of things that have been in progress, for you know what seemed like way longer than the time that they could have been done in, and I think that they were all kind of like worked on in fits and spurts right yeah, um but in in the end, I think it's, it's really nice to see that those important things people do care about them and they do make the time for them eventually, um and a lot of that I know, is brian.

A

uh So I I appreciate your work on that a lot brian.

B

Well, it's nice to see all this stuff get done. Yeah and stuff gets really really close. It's usually just getting it over. The finish line is the hard bit. Usually it's like. Oh there's a couple few things that we got to wrap up and.

A

Like persistent l to work, I think must have had at least like four different owners over at least five years, if not longer um and uh yeah. So that's that's great.

C

Well, you know what they say about software. You know once the first 20 is done, everybody's really excited, and when you get to about 80 everybody's mad, because it's not quite perfect yet and then someday, maybe it gets to actually be finished.

C

A

At least finished enough.

C

Yeah all right cool.

A

C

Guilty as everybody else, I have, it's, gotta be five or six pull requests at that. Eighty percent point.

A

Yeah, well, uh you all know that I'm working on um raids, the expansion and have been for years, but that's that's getting closer as well cool. Well, uh thanks everyone- and I will see you again in four weeks.

A