OpenZFS Leadership, 28 Feb 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: February 2022 OpenZFS Leadership Meeting

Description

Agenda: Block Reference Table; Encryption bugs; Blake3 checksum.

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

A

All right welcome everyone to the february open, cfs meeting. um We have a couple of interesting things on the agenda for today um update on the block reference table.

A

uh Encryption bugs, let me see, is rich said he might not make it so we'll see. Who would like to go over that and then a question about the blake 3 checksum.

A

Powell, do you want to get started.

B

B

Okay, uh let me get my notes.

B

Okay, uh so uh just a reminder, brt is a block. Reference table uh is in some way similar to dedupe. It allows to manually clone specific, given blocks it's similar to reflect from linux basically, and we can clone individual blocks or we can clone whole files, but the idea is that we only create block pointers that will point at existing data.

B

It will keep track of of those similar in a similar way to the dedupe that we have a separate table that we keep those extra references.

B

Okay, so uh I think the code is uh like, I would say, 98 percent ready. I will subtract sidetracked a bit with a small security issue.

B

In zfs, this is really minor so, and I think we almost have a final patch ready to to be merged. Hopefully,.

B

B

After my uh last update.

B

There is some changes, for example, uh there was some interaction between dedupe and brt, so there is some like.

B

We could, uh if we had a block that existed in both tables uh we had to choose from which table it should be freed first, and both selections have some some implications, and alan came up with interesting idea, which we implemented, that if we are going to clone a block that already has d-dub flag set, we will just increase the counter in the d-dub table and we won't put this block into brt at all.

B

So we will be reusing, what's there already and not creating another entry. So I think that was a very good idea.

B

The code is ready for also situation where, even though the block has deduped flag set, it doesn't exist in brt, because we hear about those ideas to to be able to to remove some blocks from the table, especially those with just one reference.

B

So I wanted the code to be ready for that and I implemented some uh some missing bits to uh to try to close and complete the implementation so stuff, like enforcing file size, limit range, locking of the source files enforcing quotas passing I o flags, so we can tell if we should use zeal or not update a time on the source files on the source, file and stuff like that.

B

uh The zfs clone file function initially was in the freebsd specific code, but I rearranged the code to to have as much system independent code as possible. So most of the code is now available to everyone to use.

B

I implemented fclone range system call for now, um because the going code itself allows to clone blocks, but the cisco I implemented initially allowed only to clo clone entire files, because that would be probably the most common uh use case, but I also added uh because it was simply easy to do f. Clone range, cisco that allows to clone any sets of blocks even within the same file as long as the ranges don't overlap.

B

Also, I fixed the back where it was. It wasn't possible to read from cloned blocks before transaction group was synced, so that was fixed and one of the big missing bits was zeal support, so this is now also implemented. So uh the problem here was that.

B

This cloning blocks is a bit different than all the other system calls and operations because we can have source and destination files in different data sets. So for zeal. I didn't wanted to reference data set that it's, maybe I don't know uh not yet available for some reason, or so I didn't wanted to use uh file ids from different data sets, so I had to implement uh replay totally different.

B

So now I log uh just bps that I want to clone and I don't reference the the source file at all, so the zeal support is implemented. uh I wanted to thank christian for for his reviews and comments and discussions. So thank you christian for that.

B

uh Apart from that, uh I think some tests tests would be nice to have so. I would appreciate if someone pointed at the right direction, how we could test that or, if there's any similar, uh maybe how the duplication is tested now. uh So maybe I could work on something similar and uh there is also one more item I'm thinking about implementing, because now the uh the block reference table is a single large table and the key into the table uh is vdf id and offset.

B

So we have those two 64-bit uh values as a key, and the counter, of course, is the the value of the of the element in the table. uh But the vdf id is repeats often right. If we have just a bunch of vdfs, then most of the keys share 50 of the. So basically we have.

B

So we have 24 bytes of data right, 16, 16 bytes for the key and eight bytes for for the data and so 30 33 of this repeats almost in every entry. So it's probably not a huge space savings, but it just bothers me that we are repeating everything, so I'm just considering to splitting brt per vdf. So we we won't.

B

We won't store bdf id anymore, just the key will be the offset and and each vdf will have a separate, separate table and that's pretty much. It.

A

I mean that would impact memory usage as well right.

A

You would hope that this brt is mostly cached right.

B

Not really uh so uh not sure if I mentioned that in the past, but uh one of the big problems uh was that when we free a block we have to reference, we have to look at the brt table because we don't have like specific special bit. As for the duplication for the duplication, you only consult the the table when the bit is set for brt.

B

We we don't have that, but what I implemented uh to uh to work to to make this uh work better than the duplication and it can work better with the duplication, because we, the key, is not random. So it's not spread across entire pool.

B

I I I now I split the vdfs in ranges like every few gigabytes and- and I keep like and I keep how many references are within this range. So uh this array of ranges and and those counters within ranges is very small. I think it was like.

B

One megabyte per one terabyte or even smaller- something like that, so uh it's very small, so uh what it can it allows us to tell is that if there might be uh if the given block might be in the brt, so if it is, then we will we will go and uh and uh and consult block reference table, but we can immediately tell if it's not, and so, if we clone even a very large file uh chances are all those blocks will be within a single range, so that will just single entry with the duplication, because we use cryptographic checks on this will be spread across entire pool so for dedup it wouldn't work, but for brt it works very, very well.

B

But yes, if someone will use brt very heavily and have clones across entire pool like then then, yes, that would impact memory uh as well, I'm sure, because of course we want to cache as much as possible. So this entry now will be. If I implement this tweak, it will be just 16 bytes per block.

B

A

Yeah, you might even be able to get away with like a 32-bit ref count, um saving even more space. There.

B

Yes, yes, even for.

B

Yeah, the offset also might be uh we can use the like. uh You can use blocks for offsets, not, uh but it won't save us a lot so instead of using byte offset, we could use block offset. Let's say so: we save few more bits, but.

A

Yeah, you could do that and then like um either use those bits for the ref. There might not be enough bits there to use for the ref uh count, but you could like use those in case the ref count overflows the 32 bits, or maybe the refcon is 16 bits, plus the height plus the bits that you have left over in the offset. You know something like that to squeeze it as squeeze as much as you can to fit it to fit stuff into memory.

A

I don't know if it's working equipment that far but um yeah.

B

I think that seems like it probably is, I think, with those counters within ranges, I think uh it's no longer like a huge problem. I think the problem was solved with this one so uh before uh it was a concern of mine that will basically end up with the same problems of as the duplication, but.

A

How big are the ranges that you're chunking it into so like.

B

um I I don't remember exactly the.

A

Smaller those ranges are the better chance you have of getting one. That's rough count of zero right, yeah, of course, of course,.

A

um So I mean hope, hopefully, like you have enough memory that the to store those, even if they're, pretty small, like I don't know, 16, meg or 128 mag, or something like that.

B

Maybe I can look it up quickly, but so now I'm using one gigabyte so and this.

B

So, with one gigabyte range we need eight kilobytes of memory per one terabyte of vdf.

A

Yeah I mean I I would consider going like so you could get cut this. You said that the range was one gig.

A

You know you could go to one meg and still it's eight megabytes per one of ram per terabyte, which is like I mean that's way on the other end of the spectrum, but I think somewhere in the middle probably will will make sense.

B

But one gigabyte, I think it's well.

B

I was actually surprised with the calculations, but for me, even one gigabyte was like very small, because normally, when you clone a file, you probably want to clone pretty large file right. Okay, so one gigabyte file is not that big and the whole file should uh should be should fit into a single range, because.

A

Most likely the.

B

Blocks are contiguous on disk, so.

A

Yeah, I guess I was thinking that people might use it to clone like a bunch of smaller files. Like you know, I it's not just like my one disk image, but you know once this is available and easy to use. People might be like. Oh, like I'm gonna, cp r. All of my photos that are each like a couple. Megabytes and cp is just you know using your brt under the table to not have to actually copy the data.

A

Then you know you might have a lot more small files that might have been allocated like a little. You know all over the place, not necessarily I don't want to kill my files, but like medium-sized files. I know.

B

What you're saying, but uh just to put it into perspective, like we can have one megabyte record size right and uh with this space optimization, let's say we have 16 uh so for those blocks that are one megabyte and for ranges that are one megabyte. It's a matter of like if it's. If uh this range table takes eight megabytes for one terabyte or if brt takes like 16 megs per and one terabyte.

B

So it's not. uh I think one.

A

B

A

You have those big blocks, then um you probably aren't having problems at all with it. Right, like the whole brt will be cashed in ram rate.

A

So I guess maybe the the argument that you're alluding to which I think I agree with is like either you're cloning files that um are laid out that are like have large record size, in which case the brt is small or you're cloning files that have small record size, in which case the files are likely very large right, like if you're cloning, a large file like a disk image or a database or something, then those are the cases where the records, where you have small record size, medium sized files wouldn't have small record size, and so that's kind of why your the solution might work out really well, because you, because, like either you're cloning, these medium-sized files with large record sizes, in which case the number of entries in the brt, is small or you're cloning.

A

These huge files that are have small, maybe may have small record size, but they're laid out. You know in in in sections of the disk that you can use this. um Like summary info to reduce at least reduce the cost of the brt manipulations for freeze of things that are not actually involving it.

B

Yes, image files are a good example, because those are large files, you can have small record size and they can also be scattered across the pool once you start to use them so yeah.

B

I just really have a strong opinion. I was actually. I was thinking that one gigabyte is already very small range, but we can always go smaller. That's not a problem yeah. I.

A

Mean it seems like you, have you have the flexibility to go at least maybe not to a megabyte but like to you know, somewhere in the middle yeah somewhere.

B

A

The middle you know a tenth of that or something and and your memory costs are still tiny.

A

So um so then you, you know you're using that to reduce the cost of the freeze when the brt is not involved. You still have to worry about the size of the brt. For those small record size.

A

Small, you know small record size cases uh when you are like actually freeing one of these clone files right, because you're going and documenting the ref count, then.

C

B

Yeah, but here one when we are freeing there is not much well, we have to pay the price like.

B

Still, we have some savings, so we are not really freeing the data just in decreasing reference, but apart from like uh trying to get the the entry in the table as small as possible, I don't think there is anything we can do.

A

I think that makes sense. um Have you I don't know if you've already done this, but in the table um has an entry for each logical block? Is that right.

D

A

um Have you considered like in the case where you have some giant file and you're and, like you said it's probably laid out, you know in the same region of the disk, and then you clone it.

A

I wonder if you could like indicate in your data structure that, like this whole range of bytes, the ref count is two and that range encompasses multiple blocks that are all contiguous on disk.

B

I know it's something to do that, but, uh uh like uh I suspect it would be huge complication to the whole code to try to when you start to like cloning. Just ranges in.

A

The middle of this and.

B

Yeah, so I don't want this to be.

B

I think that uh if we decide it's worth doing, I think we can. This can be done later, because we can always split larger block into smaller blocks and and find a way to like in the future to just combine them or something like that just by editing the table.

B

So uh I don't think that uh if we even go with this code, uh it doesn't uh like prevent us to do that in the future like we are not committed to to anything that will prevent us to do this in the future, but I I definitely would prefer not to not to do that now, because I I expect huge complications.

A

Yeah, that's fair. I agree.

A

Sounds like you're, like uh you're, really far along like this, is this is getting really real.

B

Yeah, I'm, I think it's it's pretty much almost ready, so uh I yeah, I regret. I I uh stumble upon this security issue because this took a while, uh but uh but yes, the code is pretty much ready.

A

And for the logging that you mentioned, um I assume, like the the overall clone operation, might be like, including some giant file and uh are you I assume you're like splitting, that into smaller log records, where it's like just like, when you do a huge write system, call we split it into like one mag or something log records. Are you doing something similar where it's like?

A

Actually the atomicity is or the like, you know, the durability into the log is on a one bag or one gig chunk that you can collect all the block, pointers and log it together.

B

Yes, I pretty much mimic. What's uh how right is is done, so I split those of course into larger chunks than the rights, because I'm just uh storing kbps but uh yeah cool each chunk is stored in different in separate transaction.

B

Sorry, no! No! It's starting separate uh records in the log yeah.

A

Yeah yeah, like different transactions in the um in the.

B

But cloning is also cloning itself is also uh split into ranges as well. Just like writes that we open different dmu, separate transactions, yeah cool.

E

um I haven't had a chance to look at the latest revision um so which sys coils are hooked up to this mechanism. Right now, you told talked about f clone range or whatever. I think that's a freebsd thing.

B

No, no, those cisco's, both cisco cisco's are new. There are nothing like that, but in freebsd you can implement cisco's in kernel module, so there is fclone file where you can clone entire file and fclone range, where you can clone just selected range.

E

uh Are you planning to like? Are you aware of linux's coil that provides similar functionality, or are you like planning to implement any of that.

B

B

I'm not really planning to do that. I hope it will be easy enough for someone to do that, based on the on the cisco's I implemented for freebsd, uh but uh I think that in linux it's either ioctyl or some other way to uh to use rafflink. It's not really a cisco. Okay. I remember.

E

So for f-link uh I think yeah that should be.

B

Macos macos has a separate system called to do that: okay, but mac os, also the difference between macros and what I did is that they they have like a clone file system, call where you provide uh paths to the uh to the files, not file descriptors, and I decided that I don't want to replicate entire logic of uh copying, because the clone file in macos tries to copy all the permissions or the acls and stuff like that to the target file, and I decided that I don't want to really duplicate this logic.

B

You can always just use open to create the file and just pass this descriptor to fclone file.

E

Okay, I did a very quick google search and found copy fire range for linux, but I don't know whether, like what the cloning semantics are- and I think alan pointed that out as well so freebies has it as well.

B

Yes, I think that when I looked the rough link in brt in batterfest was implemented using uh iota life. It wasn't system called, but uh uh but maybe something changed or I don't know.

F

Oh, I I think it's actually still a system call or not a system called sorry an iactyl, but it would be kind of cool to wire up, because then all of the existing command line tools would just be able to use it, and it would just work on linux, which would be pretty cool.

B

But it should be possible to implement it as an ioctal for linux right.

F

B

F

B

C

Well, a small question: you mentioned uh it implemented for files. What's about the walls, is it uh general enough to be used to obstruct.

B

Any object, yes, I forgot.

C

To mention that.

B

But uh yes, it can work on zebras just as well. uh I didn't came up with any interface to do that, but you can definitely do that on zebels too you. We just need some kind of system caller some some way to to get to some interface to do that, but it can be.

C

Done I just really like it to back vai iscsi offload. It would just map like read here right there. It will just map one area of the volume to another area of the wall. Maybe different evolves in the system.

G

Yeah, that's what I was thinking too, is that you could use it to implement. That is because you offload stuff- and just you know that way, your vmware or whatever just says. I want that over here and you can do it almost instantly instead of having to actually physically copy the range.

C

Yeah right now in ctl, just practically it is here right there trying to pipeline still faster than the full copy of science escapes network, but still a lot of work here. Nice.

B

Chances I wasn't aware about this in iscsi yeah. That's why I didn't want to implement something because I was expecting there is some something exists already and so yeah, but definitely it can work with zebos.

A

Yeah, so it sounds like um the interface is uh like you have a new interface that you've implemented for freebsd.

A

um I think it would be probably important for people for like this to be used widely to kind of hook it up with the most popular existing interfaces, um which is probably the I'm guessing the linux reflect stuff.

A

um So you know maybe, when you're ready, um we can try to find you know who who would be interested and able to to work on hooking that up. um I think that would increase the like utility of this. A lot.

B

Yeah definitely roughing as far as I know currently in linux, it is used by xfs and battery fs right. So definitely if we will just use the same mechanism, it would be immediately available.

A

Yeah, it would just work with all the tools that were written. You know for ref link.

B

Yes, for freebsd, there is nothing like that as far as I know so we will need to. We will still need to work on the tools to to be able to to use that, although I was also wondering- uh and maybe you guys have an opinion- that about implementing some kind of like demon that can work in the background and find stuff that can be deduplicated, of course, with snapshots.

B

It won't work exactly as expected, but it also.

B

So the idea for me was that the demon would walk through file systems and just read blog pointers and checksums. So it should be much faster than reading all the data. So we would need an interface for that as well and and then, when we find when we find duplications in the in the data, then we we could use brt to clone like older block to the to the newer one, and uh even if we have snapshot the other block would stay.

B

But the newer block wouldn't take extra space. So I think it's not. uh It might be.

A

Before the snapshot comes in right,.

G

Of course yeah that would be best and once it's it's brt'd, it has the same dva, so you end up only caching it in the arc once which can help there as well.

G

You know, I think my initial idea for this is even maybe not going as far as the daemon, but just a command line tool to be like I cloned this this disk image months ago.

G

Can you go through it now and find any blocks that have changed since I cloned it, but are the same again now, like I installed the same windows update in two vms or whatever, uh or especially things that were actually like, zfs clone, like dataset clones uh and they've, just diverged a lot, and can we find blocks that are common between them and and turn them into references instead of taking up the extra space.

B

Yeah well, the demon would be nice because I think that there are some systems already that use offline duplication like that that when the machine is like less busy, the demon would just start and walk and try to find what can be duplicated and especially if we will uh came up with the interface that can read only block pointers. So this should be much much quicker than just reading all the data and and based on the checksums.

B

If it's not secure check, something will, of course compare the data as well, but uh if it's, but still so so, this demon could be really like, quick and also if, if we can also came up with interface, that allows us to to swap blocks without, even because, of course, we are working on a live file system. So the file can be in the middle of changes, so it would be also nice to be able to swap blocks to have a mechanism to swap blocks like atomically.

B

So, even if somebody is actively writing to the file, we can still swap block if it's not actively in use and make sure there is no race between reading the block and replacing the block.

B

But just just a thought.

B

Okay, you don't know other comments or questions. Thank you very much.

A

Thank you cool thanks.

A

um Do you have any thoughts as to the timeline of when you'll open a pr.

B

uh I know this is just like, as you would like two minutes- open open pr as soon as possible. Well, first, I would like this uh security uh issue be solved. First, because I depend I I I depend a bit on the fix, because this is how I found it. I needed this for brtt, so I want this to be merged.

B

I want to merge it to my branch and then- and I think it's pretty much ready to open up pr. It will be still missing tests, but uh I think it would be good to start a discussion and and see what people think about the code itself.

B

If, uh because I don't yet know yeah, I know that christian was taking a look in the trip, the entire thing or just the zero part, but it needs more much more review. So I think the code is pretty much ready for pdr. I just need this security fixing device. That's great, but no promises who knows.

A

Thanks um thanks christian for taking notes, I see you typing in there in the doc um next. Should we talk about encryption? Bugs um is rich here I don't see your name. He said he might not be able to make it. um Is there anyone else working on this? I would like to speak to the summary of what's going on with encryption bugs here.

H

I could take a shot. uh Can you hear me yeah? Thank you. uh This is george amanakis, so um I was actually involved in solving uh two bugs uh one of them. I see rich mentioned in the document.

H

That was a problem mainly uh when ross sending snapshots to a target and then trying to send them back to the originating file system. um That was not possible because of uh the user accounting being present. So we decided to work around that by actually resetting the flag uh in the hospice of the of the file system and.

A

H

To indicate that there isn't accounting data.

A

H

uh Yes, it's actually indicating that it's not complete, so uh when we're sending it back, it will bypass uh comparing the local mark, and so it now enables the sending back of snapshots to the originating data system and as soon as the key is loaded and the file system is mounted, it will go on um complete to complete the user accounting by um counting the the the.

H

By including the new snapshot that was sent back in the user, accounting and the flag will be set again. So um that's how we solved that, um so the user accounting is, is always there. The big nodes are they all d nodes are not touched.

H

It's just a flag in those space that indicates that the user encountering uh is not complete, so don't go ahead and check the local mac uh when, um when robo receiving so it's only, it was only a matter of skipping the comparison for the local mac in case of raw receiving cool.

H

There was a second one that it's not mentioned. It manifested as a as an error, an unclear error when um again rose ending and receiving snapshots, um but it was actually so that was, I think, issue 12 720, so 12 720, um where it manifested during gross ending. But the issue was only because the encryption code path was changed, was checking for uh discrepancies between the denode bonus length and the denote spill pointer flag, so actually in very early releases of open zfs.

H

This dates back to the 0.6 branch. I think.

H

There was a fix we could have denotes written on disk where actually the bonus length and the denote spill pointer flag were not in accordance with each other, so we could have written such denotes on this, and now the encryption code path, when raw, sending and receiving would pick this up and just error out.

H

So I went ahead and filed a pull request. This is uh 13014, so 13, 000, 0 14., um where we actually, uh when we encounter such body, denotes uh whose bonus length is actually greater than the predicted one when accounting also for the denote spill pointer flag. We report an error and this is done during normal raw receiving and also during scrubbing.

H

So now, when you we do a scrub and we pick up such faulty uh d nodes. We report an error, and I also added in that we are an assertion at the end of uh dump of denote sync, so that this um this uh it it can actually check for this discrepancy. There, too,.

A

That's great thanks for all of your work on this sure.

A

um I saw that there's a few uh things mentioned here in the notes that rich put in about um works in progress. um Do you know, uh do you know the status on those? Do you know if um he's looking for help on those or if he's making progress on them.

H

um As far as I so from the the other things that richards mentioned there, one uh bug that has draw lots of attention because uh people are encountering it all over again is the eleven six seven nine. um As far as I can remember, he mentioned that in the last open, cfs leadership.

H

Meeting too, I think he thinks that there is a problem with the um ref count, accounting either in the r code or in the debuff code, uh codepaths that actually the the the ref count account is not done correctly, and so we can release a debuff and then in the code path, for example, of tip of right and then deepa freit is going on to access it and it's not no longer there, so it uh it panics with a new pointer the reference, um I think also he has submitted a draft pr, but I don't think it's it's final at this point, so I think he's still looking into it.

A

Okay, yeah, I see the issue, I'm not seeing a linked pr, but maybe it's just buried in here somewhere.

H

I can quickly, uh let me see again it's it's a draft pr us. As far as I can remember,.

A

Let's see on the last page.

F

Looks like it's twelve, nine, four, three.

H

Yes, that's it twelve, nine four, three.

H

As I said, it's uh I think it's. This is only a draft pr. um He um he he actually is going over the locking to see where, um uh if, if, if something um can be, if the the backing bypassed with uh um manipulating the locking, but I'm not sure that we actually know that the problem is there, it can also be a problem in the in the r code, but with with the rest count accounting.

A

All right um well, uh it sounds like it would be great to have more folks who are familiar with the dmu. Take a look at that pr and the analysis that he's done.

A

It looks like he has a bit of a write up there explaining what's going on. So that's nice.

A

um Any other thoughts or requests for help on this encryption stuff.

A

All right, then, um let's go to the next gen item, which is the breakthrough. Checksum tino added this item. If you're on the call.

D

Yes, I am here hello yeah. I just wanted to ask if the three check some stuff is ready for inclusion or if there is any anything left to do for me. I don't know, I thought it works nice. I test it and it seems also very fast.

D

I don't know if, if you are, if you have seen some benchmarks against, for example, new instructions from intel break 3 is mostly faster.

D

I may put some benchmark results into into the shed.

A

Sorry, my web browser just died. While I was trying to bring up your your pr.

D

Why or you go into the pool request and then in the end there are some benchmarks about a month ago.

D

There's a list.

A

um I mean I am not that familiar with pr, but I think that uh the idea of adding that sounds good to me hasn't even take taking a look at the pr.

A

I got the pr, I see your benchmarks.

A

Let's see a couple of.

D

uh That's that's the micro benchmarking like it's done for fletcher, it's the same meaning and for a 1k block for 4k, 16k and so on and up to four megabyte block and then the throughput in megabytes per second cool. I even implemented a char tool, I've written with this, but but it's not still requested. I would open this when plague is in and then I would also do some stuff, then some different implementations for avx and and then generic and shiny instructions and so on.

A

um So the pr that you have does that is this.

D

Just the like three, that's just the break three stuff and uh the benchmarking of of is it implementation of the benchmarking uh zooming and then in a later pull request. I would also uh maybe add for for sure, and maybe also screen, assembler stuff and then also some benchmarking and then the fastest implementation is chosen uh when the module is inserted.

D

A

See, um and is your does your pr include the like the avx versions of blake, three okay cool um yeah? I mean those numbers like great. I mean it's way beyond. You know. The avx 512 is like uh what like four three times faster than e dot r and like 10 times faster than shot. So that's that's really impressive.

A

um The um in terms of the security of this of a blake three like I'm, not that up on um is this a replacement for shot in terms of like we can use it for.

D

I'm not a cryptocrafter, but it was, I think, in the shah 3 contest within, but not not. This break 3 not but break two, and it was.

D

Second place or the third I don't know and break three. Even this is a more advanced break two, and so I think it's safe, but that's not my. I don't have enough plan of this. I don't.

A

Know um well in your in your pr, are you allowing it to be used with dedupe without verification.

D

Dwb is working with this. I tested, I don't know how to more tests can be done because the testing and setup, and so on uh it looks nice. I think I have run it for some hours and it should be okay. I think.

A

Sorry um I mean that all sounds good to me. Are any any thoughts or objections from other folks.

B

I think we should really talk to uh some crypto expert uh if we can use this without verification, if it's not the standard.

B

Function, I.

E

B

I mean the credentials.

E

The credentials are pretty good, but um I post the link in the chat, but um I don't know like what was the benchmark for the other um checksums that were used in like who, who admitted them.

A

um Well, I think that I think that the idea was, I I mean, probably me or um or brian like gave our stamp of approval, um but I think that the idea of the other ones was that, um like they had been kind of vetted extensively by third-party, you know stance of approval um and the goal I mean the goal here is basically just that you could use it for d-dupe and nobody can generate like a matching key um or like, like nobody can generate another block that checksums to the same value as a given block.

A

um So they can't, like you, know, essentially corrupt your data like if one, if there's two people writing to the pool they're, both using dupe you're, not using encryption.

G

Right, there's no known way to craft uh collision on purpose.

A

E

So black three, that is it. I think that is the definition of a cryptographic, checksum and blake. Three was a contender in the shark contest by a quite renowned cryptographer. I can ask someone who is like doing a phd in cryptography to weigh in on this. He is also a previous opencfs contributor, so I don't know he has some domain knowledge. I think that's I can reach out to him.

A

Yeah, I don't know, I would agree.

B

So uh note that blake 3 is 2 years old, almost exactly so. It's very young still.

D

Yes- and it was designed to be fast and also secure, in the same time,.

H

B

Every algorithm pretty much is but with cryptography.

E

Of course, the older, the algorithm.

B

The the more peer review it had and uh but of course it would be great to have like very fast, very strong, securely strong checksum. So.

A

But yeah yeah I mean given the performance, I mean I'd love to see it in even as an alternative to eat on r, which we don't um except as uh using for, but um you know it can be used for.

A

I think we use it for um an operate detection um and it's obviously much much stronger than fletcher. uh So you know if, if, if we weren't going to use it for d dupe, then it seems like the bar is already met. um I guess the question is like: are there? Are there any concerns about? You know unknown vulnerabilities that might um make it not appropriate for dido.

A

I think that was the concern with um with elon r and that's why we didn't make it. What.

B

Is the difference? What is the difference like security, wise between dupe and nope, writes.

A

Well, with an operate, um you don't really have to be concerned about an attacker. It's only like accidental matches that we have to worry about, because you know, if you can, if you can write to that location, then obviously you can write whatever you want, um and so um you know we weren't really concerned with uh the case where, like an attacker, can control what's written but then, like not, um you know we were all really worried about.

A

Like you know, if you can control what's written, then you can write whatever you want, and so we weren't worried about somebody intentionally. Writing uh nefarious stuff.

B

You would need to have like intention to to keep what's there already that some something is like malicious or yeah. I mean.

A

You want to be right exactly like you know, I'm sure that somebody could come up with a scenario where there's a lot of parties involved and one of the parties just right just gets to decide what's written and you know they somehow like they, like their array, is going to get lost because they've constructed it so carefully.

A

um But it seems like I don't know how you would use that to actually cause anything bad to happen to anyone. But yourself.

A

So I think that's why the bar was lower for that.

B

Because so um yeah it's, uh it's definitely different uh different, like uh level of threat, but uh but it's also important like you, you definitely don't want to leave like a vulnerable binary only because the updated binary have the same checksum. So we definitely don't want this to be accidental, that it's possible to generate something similar because, like uh I also give, I give this example.

B

Sometimes uh in terms of like reproducible builds where open ssh had a bug and uh the binary of open ssh, the the secure one and and the the vulnerable one was only one bit different, uh because there was only a matter of changing the I think less signed to less equal so uh and the binary resulted in uh just a single bit difference.

B

So uh but yes, it's you're right. It's much much much harder to exploit them.

A

Yeah, um I think we're we're almost moving to the end of the time. I have a meeting right after this, so um why don't we go on to? uh Well, I guess, let's conclude this by figuring out like what are the next steps needed to get this integrated? I think one of them is um to have uh this person who's working on their phd in cryptography, to take a look at it and and just tell us if they think, based on kind of the consensus of cryptographers.

A

Does this seem like a relatively safe thing to do for this use case now,.

E

If I've had mentioned in the opencfs, slag channel will respond there.

A

Cool thanks um and then on the code review front. um Do you look like a few people had started looking at it, do you need more viewers, or do you need those reviewers to take another look.

G

uh I don't know I just need.

A

This this is about the like three. Oh sorry,.

G

D

Oh tino, do you know I am I'm here sorry.

D

From my side, uh it seems to work. This is a break three checks on this from cryptographers, of course, and uh but I I cannot speak for them. Yes,.

A

I guess my question was about the reviewers um like uh rich and uh another person's name. Ha6. Are they um do you know if they're planning to do a review of like the zfs parts of this?

A

um I don't know. Okay, we might need to coordinate um and mark I see you're on but mark is the.

D

Mike yeah mike, of course, should maybe uh say something about it: uh rind uh just tested uh the arm stuff and uh also did the implementation of the neon code, uh which is some assembler stuff.

A

um Sorry guys I need to drop but uh mark. Could you uh just give your thoughts and finish up the call for george.

I

Yeah yeah thanks yep, I had a drop so yeah, so I'll definitely follow up uh with some the code, reviews reviewers and and uh and make sure that uh they're happy with things um and um I'll, probably even take a look at it. Myself um was there. There was another final item on the on the list. Is that right that I've?

I

Sorry? I wish yeah.

G

I just had uh a bunch of code reviews I have pending uh okay.

I

G

We would like to get wrapped up. Okay,.

I

That's that's probably also me.

G

I think one of them is uh at least one of them is someone other than you.

I

Okay, a bsd one yeah.

G

Well, there's the linux namespaces one uh support.

E

For delegating.

G

uh Dataset to a namespace on linux and basically implementing something similar to what freebsd can do with jails or alumos with zones right um that one's been sitting there a while. I think the only thing you know there's some idea. We wanted to somehow uh take a reference to the name space, but there doesn't seem to be an api for that.

E

Like in linux, it's right, it's.

G

Linux's poor design- I don't know.

E

G

uh What we want to do about that one and then there's the spa inflation, one uh just figuring out what that actually means uh and then there's the uh the right swaddle one, which I think uh alexander gave us a good review on that one, and we uh made some changes based on that found a brain oh in there, uh but would like to see what's required to move forward with that.

I

Okay, all right I'll uh I'll I'll follow up with the ones, at least that are that are assigned to me and I'll see. If I can ping uh the anybody who's who's, not uh me who's in charge.

F

I

F

No I'm on the hook here to take another look at a bunch of these too. All right I'll do what I can all right: cool.

I

All right do we have anything else today,.