On Sat, Jun 14, 2025 at 04:11:33PM -0000, Christos Zoulas wrote: > In article <102k6l5$u8i$1...@ciao.gmane.io>, > Christos Zoulas <chris...@astron.com> wrote: > >In article > ><cao5qjjvt65vay7rsqk8jgcj_h8ipwymyd5dkuko8cgv+rsj...@mail.gmail.com>, > >Joshua Gillett <joshuagill...@college.harvard.edu> wrote: > >>-=-=-=-=-=- > >> > >>tech-kern, > >> > >>I wanted to follow up. I’m interesting in doing some work on this and > >>wanted to know the feasibility of and if there was any more information > >>pertaining to the project. > >> > >>Best wishes, > >>Joshua Gillett > >>Harvard College ‘27 > >>A.B. Candidate in Computer Science > > > >Hi Joshua, > > > >There is some low level support in NetBSD for trim in the device drivers > >(wd for example), but there is no ioctl interface, filesystem support and > >of course no userland trim utility. I would check out how FreeBSD does it > >first and model it after that. I would start with ioctl support, then > >userland utility support to test and finally I would start adding support > >to ffs. I think that we would need to update our zfs code to support trim. > > And of course Greg is right, there is fdiscard(2) I missed that. There is > also a long discussion about fdiscard and the ioctl approach in this group, > so I would start by reading that.
In addition to what Christos and David said, I'd like to suggest that you look at what Linux is doing and how that came to be. The main things I have in mind is that they added fstrim(8) utility, mostly to run it weekly to notify the drives about unallocated storage, and that their file systems seem to collect trimmable ranges and send them to the drives in batches and, perhaps, during times of low usage. Apparently some drives become very slow to respond to other I/O requests while performing trim operations. --chris
