 So these talks are fantastic, right? Because you hear hallway conversations or you hear questions and they bring up things that you guys might have ideas about. So this isn't a lightning talk. This is a lightning quiz or something I don't know. Questions. So one of the things that came up was like U-mount, the complicated U-mount things. If you guys have any ideas on use cases where adding a helper to begin U-mount would be helpful for use cases. We have a few, but that would be good to know. In one of the talks, there was a discussion about some really cool scenarios revolving around hierarchical storage management. And that brought back what use cases we might have for those two flags we've talked about in the past for offline, whether that would be of benefit to more than the three or four file systems that have asked for it before. And hopefully there's no pushback about that. Then a couple other things I was diving into. I was looking at XFS tests in some detail because we've been talking about test automation. And some of the things that came out are are there any examples of network cluster file systems or fuse, anything other than a local file system that supports auditing, defrag, verity, or I think there's one other example. But the reason I was asking is would there be a reason for enabling these more broadly across non-local file systems? So these are kind of the questions that came up today as I was thinking and wondering if you guys had any opinions on that on any of those. Because I was trying to look, for example, at test cases that today are skipped for a large number of file systems that maybe didn't have to be skipped. There are plenty of examples of that, but those are some that came out. So if any opinions on that, that might be a good thing to kill a few minutes while we're waiting for the EBPF people. I mean, I think I don't know of any, but I would suggest that instead of it being enabled for remote file systems, that it's just on a per file system basis. So I've talked to some folks in NFS land about what if they want to implement verity for NFS? They haven't. If they did, they would just simply add NFS to the verity tests, right? I don't know that. I think what tests get enabled or not is something that we probably need to do on a per file system basis. So as file systems add the features, they can add those tests, right? I mean, your example of NFS is a good one, right? There may be very easy things that can be done that may only need one IO control over the wire or something like that to support some of these. But in the example of a lot of these, we already have the wire stuff for it. But what we're trying to figure out is if there's any pushback to sort of plumb these into the file system layer, or at least make an optional place. And an example of this might be defragmentation, another example might be auditing, another example might be whatever, if there could be others. Yeah, I mean, ultimately, again, I think someone has to actually implement it, and the file system maintainer has to accept it, right? So defrag doesn't have a standardized interface, really. So that one's probably kind of a special case. But auditing is pretty simple, right? And a bunch of these are just, you have to accept the way the local disk implementations have all been done rely on certain extended attribute layouts. And there's nothing stopping a remote file system for adding that support to their remote file system if they want. But I don't know that they need to ask anybody's permission other than the file system maintainer, right? I mean. And the beauty of this is that for both the SMB case and the NFS case, we've got kernel servers. So I mean, this isn't a big deal to add a little tiny little lioctal across the wire or something if we need to. Yeah, it's a protocol extension, right? So as long as you have a vendor extension that you could add, like the Linux vendor extension for SMBFS. Yeah, that's consenting implementations can do whatever they want, right? And there's a lot of precedent for this. Apple, for example, does this over SMB. They had little tiny extensions. Hyper-V, virtualization guys would add a little tiny optional extension if you didn't support it in a big deal. But these are easy. And part of the reason for this is that I get paranoid because we had an example today where we were debugging an XFS test. And what we found was when we got past the dumb easy XFS test problem, we found the real bug. But 90% of these things that are skipped in XFS tests are masking, sometimes, other bugs that matter. And we had that example today, right? Where we found a bug in caching something else that we never would have noticed if we hadn't debugged the silly little shutdown problem. So this is kind of my paranoia about XFS tests. I want all file systems to run as many as they can. Yeah, I mean, again, I would like some of the file system maintainers to run XFS tests at all. So I guess I have much lower standard than you do. But in terms of an extension, the classic one would be the 9P 2000L extension. So you actually had Unix mode bits added to the 9P protocol, which didn't have it before, right? So we do that all the time. Yeah, and I think the Sombax P is going on right now. So it's a little bit of an odd thing. But at Sombax P, there's three or four talks the Somba guys are doing on their POSIX extensions, right? And implementing FIFOs and reparse points to handle block devices and care devices exposed over all those kind of little trivial things. But as they make progress on this this week at Sombax P, we'll even have other servers, not just the kernel server, that are helping us drive to running XFS tests for everything, not just for the 40% or 30%. We can run the day. But I just want to make sure there's no big pushback from file system guys on kind of maybe plumbing a few extra calls, because there's some obvious ones, like we've talked about, right? That there's no particular reason wouldn't be sent over NFS or SMB or SIF or FUSE or whatever. Right, I mean, I think all of that code would be in SMBFS or FSFs or whatever, right? So I don't think the core VFS folks would care, right? I mean, the example like I Notify, right? I Notify had really small things. Anyway, I don't want to take up too much time on this, but if you guys have feedback on that, I'll, you know, I'm here this week. All right, one odd lightning talk, I guess, until a BPF folks come back. I was curious if folks have looked into StressNG. Okay, is there anything there that's missing that would help us test file systems and can we replace some of the stuff that we have in FS tests or block tests for stressing file systems with StressNG? Yeah, sure. So the context here is StressNG has a glorified iterator for doing loops and a lot of these tests sometimes can be pretty insane to the point, you know, your system will definitely be hosed. So I have been running it for some of the things that I like to test and it definitely has helped capture a lot of bugs. But I know that NFS tests and block tests, we also have a bunch of our own set of implementations for iterators for testing a whole bunch of things. It just seemed like natural to have one glorified iterator that we'll share across different, you know, system calls or test suites and so forth. So I was wondering if folks that looked into that and it just occurred to me that it might be good to bring this up here. So I've used it in testing and stuff. I think it's really interesting to use but I think the broader question is like, we have a lot of functional testing in XFS tests but we don't have stress tests. There's the load thing that you can do or whatever but when I go to the stress test butterfast, I have specific things that I go and I run on the thing. So like if we want to kind of gather behind StressNG, like that works for me. I like StressNG, I've used it a couple times. But I think that it's StressNG or it's FS stress that's sitting in XFS tests. Yeah, I mean, I started thinking about this just because I started considering updating FS mark. I know you had forked FS mark. I'm like, why, you know, updated if we have something else out there ready too? So I was wondering why not just replace FS mark with something like, you know, StressNG and extend it, you know. Yeah, no, I like, the only reason I did the FS mark thing was just like, I'd get other statistics. So like, I'm not married to FS mark. I'll use anything. Like I liked it for the statistics and StressNG does give you the statistics. So I like that. But yeah, I have no strong opinions on this. I think my having some place that we are all going to pay attention to it is useful. And this is why I like XFS tests for a lot of things. Cause like we just implement all the random sys calls that we do into FS stress. And then like all of a sudden we get like all of the testing coverage that way. Like if we do the atomic thing, like I'd want that to go in the FS stress thing. And so we just automatically everybody starts getting the tests. So it's, that's my view for that is like as long as we all kind of chip in. Is anybody else? For what it's worth, I wouldn't have any objection to wiring up StressNG into XFS tests for XFS. I mean, as it is, I already have like four dozen, five dozen VMs running. So, you know, stealing a bunch more out of a cloud probably won't kill me. That's going to make your cloud bill be a lot more expensive though. Yes, but I'm not the one paying the cloud bill. You see. See, that's that. Yeah, I mean like that's true too. We can just like hook it in. And as long as we were using it, then we don't necessarily have to copy it in, right? Just use it as a external utility. Yeah, it's not that big of a deal to just have XFS tests say, hey, if you have StressNG installed somewhere, I'll go and run various, maybe more FS related stress tests. Yeah, I definitely like that. I think that would be really probably the best way for adoption is to like have like a stress group and we just wire in StressNG invocations that way. Yeah, one thing that Zorro just merged last week or the week before for XFS tests was this sub duration knob that I added that overrides time factor. So you can say, I want to run this for six and a half days and it does. And now you don't have to compute what time factor should be on some piece of hardware, blah, blah, blah. Cause I got tired of doing that and figured, here's a good way to actually just run these things continuously in a loop. And every week I download the latest RC and go and see what's broken in that one. Usually nothing's broken. So I guess we're doing a decent good job. And I guess some of the reasons why I started thinking about these things too was looking at FS mark and how like Chinner has long for a long time been using it to test regression tests, regressions in performance for instance, and these come up randomly for random commits. And if we're going to eventually deprecate FS mark, what's the next thing to do? And this begs the question also, what sort of generic performance benchmarks can we run and should we be running for instance? So I have an answer for that cause I got tired of waiting for everybody else to join. So I have a thing called FS perf that butter FS runs every single day. And so it's just a little Python thing that you can drop in FIO jobs. It automatically runs the FIO jobs against the devices that does all the unmounts. It collects all the JSON statistics. It dumps it in a database that builds graphs. If you go to my toxicpanda.com slash performance, you can see all our results. So that's what I've done. It's essentially what I did for FS tests that we eventually just ripped out. Everybody uses FIO, FIO is fucking fantastic and it spits out all these statistics. So that's what I've done. All right, how am I going to call it?