OpenBSD 7.1 Released With Apple Silicon Support "Ready", AMD RDNA2 Graphics

[intelfx]

<...> modern SSDs don't need it.

Yeah so this is a huge lie.

[Radtraveller]

Active garbage collection firmware ala crucial… might want to take a read…. TRIM command not needed, though the functionality is needed, just run in FW on newer ssds.. which, i am willing to concede is kind of a semantics issue…. The function of cleaning up garbage blocks is necessary… whether at os level via trim or ssd firmware .. if you have a newer ssd that auto garbage collects, then trim isn’t needed in the os… as long as there is sufficient idle time provided by the user/settings ..

[intelfx]

Active garbage collection firmware ala crucial… might want to take a read…. TRIM command not needed, though the functionality is needed, just run in FW on newer ssds.. which, i am willing to concede is kind of a semantics issue…. The function of cleaning up garbage blocks is necessary… whether at os level via trim or ssd firmware .. if you have a newer ssd that auto garbage collects, then trim isn’t needed in the os… as long as there is sufficient idle time provided by the user/settings ..

Oh yes, this is a trendy myth perpetuated by people who half-understand principles of operation of modern SSDs. Unfortunately, it is incorrect, and in fact I would advise you to "take a read".

Try to answer the following question for yourself: what exactly is "active garbage collection", and how exactly does it detect said "garbage"?

The SSD is not at liberty to erase arbitrary blocks according to some logic "run in FW". That absolutely does not happen. Without a clear indication from the host OS that the content of a specific block is not needed (which is exactly what TRIM is), the SSD cannot just unilaterally decide that it's going to erase this block and put it back into the free pool.

Modern SSDs do not suffer as much if TRIM is not used, because they use overprovisioning (hidden spare blocks that are always "free") and employ smarter wear leveling algorithms. However, there is no way around the fact that if the SSD has to shuffle garbage data around (because, again, it has no way of knowing what is garbage and what isn't), then wear leveling is going to result in a higher level of write amplification and generally higher load on the NAND memory.

[Radtraveller]

“Oh yes, this is a trendy myth perpetuated by people who half-understand principles of operation of modern SSDs”

i guess those people who “ half understand priciples of operations of ssds” include the actual manufacturers of the drives eh?

Straight from the makers of the ssds :
Trim and Active Garbage Collection are useful tools that can benefit the speed, function, and longevity of your SSD. But if your operating system doesn't support Trim, it's not a disaster. All Crucial SSDs are designed and tested assuming that they will be used without Trim.

and also:


Because not all operating systems support Trim, Crucial SSDs have a special feature called Active Garbage Collection. Active Garbage Collection is a process that helps an SSD maintain optimal performance by freeing up memory sectors that are no longer in use. Garbage collection is part of the SSD itself and not dependent on your computer’s operating system. Because garbage collection is part of the SSD’s firmware, it works regardless of which operating and filing systems your computer is using.

Note: Garbage collection only works when your Crucial SSD is idle, so make sure to configure your system so it doesn’t go to sleep when it’s idling. Garbage Collection takes time to do its job, but as long as it gets time to idle every now and then, your Crucial SSD will maintain its high level of performance over time.



i think I will take crucial’s word over some dismissive “l33t” forum poster.
also, the bsd folks probably know a thing or two also…

[brad0]

Correct me if I am wrong but OpenBSD is the first *BSD to have wireless AC support, beating FreeBSD to it if my following of the projects is correct.

OpenBSD's bwfm(4) Broadcom driver has supported 11ac since at least 6.5, since they're FullMAC chipsets.

Most of the other chipsets are SoftMAC chipsets. But yes the first to actually put out a release.

[brad0]

Is this why graphics support in the *BSDs is top notch just a few releases behind Linux, but we are only just now starting to see wireless AC support and AX is over the horizon?

Well they're all different. With OpenBSD's port for the most part being the most up to date. Sync's of the DRM and drivers for the most part go LTS release to LTS release, so every 5 releases.

I doubt AX support soon. It would be nice to have at least 160 MHz channel support for the 802.11 stack and iwm(4) / iwx(4).

[kylew77]

Well they're all different. With OpenBSD's port for the most part being the most up to date. Sync's of the DRM and drivers for the most part go LTS release to LTS release, so every 5 releases.

I doubt AX support soon. It would be nice to have at least 160 MHz channel support for the 802.11 stack and iwm(4) / iwx(4).

Thank you for explaining things.

[intelfx]

“Oh yes, this is a trendy myth perpetuated by people who half-understand principles of operation of modern SSDs”

i guess those people who “ half understand priciples of operations of ssds” include the actual manufacturers of the drives eh?

Straight from the makers of the ssds :
Trim and Active Garbage Collection are useful tools that can benefit the speed, function, and longevity of your SSD. But if your operating system doesn't support Trim, it's not a disaster. All Crucial SSDs are designed and tested assuming that they will be used without Trim.

and also:


Because not all operating systems support Trim, Crucial SSDs have a special feature called Active Garbage Collection. Active Garbage Collection is a process that helps an SSD maintain optimal performance by freeing up memory sectors that are no longer in use. Garbage collection is part of the SSD itself and not dependent on your computer’s operating system. Because garbage collection is part of the SSD’s firmware, it works regardless of which operating and filing systems your computer is using.

Note: Garbage collection only works when your Crucial SSD is idle, so make sure to configure your system so it doesn’t go to sleep when it’s idling. Garbage Collection takes time to do its job, but as long as it gets time to idle every now and then, your Crucial SSD will maintain its high level of performance over time.



i think I will take crucial’s word over some dismissive “l33t” forum poster.
also, the bsd folks probably know a thing or two also…

So, instead of answering my concrete, specific questions or responding to any of my arguments in substance you decided to quote a useless marketing blurb and throw in an insult? Nice, but doesn't prove your point.

Edit: "filing systems", my ass. The poor marketing sap who was writing this blurb can't even spell properly, so yes, I believe you should take my word (especially because I also provided a reasoning and an explanation) over that clueless wall of text

[brad0]

Is this why graphics support in the *BSDs is top notch just a few releases behind Linux?

As mentioned in the release notes..

Direct Rendering Manager
Updated drm(4) to Linux 5.15.26
inteldrm(4): support for Elkhart Lake, Jasper Lake, Rocket Lake
amdgpu(4): support for Van Gogh APU, Rembrandt "Yellow Carp" Ryzen 6000 APU, Navi 22 "Navy Flounder", Navi 23 "Dimgrey Cavefish", Navi 24 "Beige Goby"

Plus additional patches from the 5.15 branch are lifted toward the latest.

[lgerbarg]

So, instead of answering my concrete, specific questions or responding to any of my arguments in substance you decided to quote a useless marketing blurb and throw in an insult? Nice, but doesn't prove your point.

Edit: "filing systems", my ass. The poor marketing sap who was writing this blurb can't even spell properly, so yes, I believe you should take my word (especially because I also provided a reasoning and an explanation) over that clueless wall of text

So, sadly, in this case both of you are partially correct:

Radtraveller is correct that there are drives out there with active garbage collection. Drives originally implemented this ~15 years ago before TRIM and UNMAP were standardized. They do it by scanning the volume in that background, looking for things like free volume bitmaps, and trimming out blocks based on parsing those. One can imagine a slightly more clever version where the drive figures out the LBA's of data structure backing things like bitmaps and tracking updates in real time instead of background scanning, but I am not sure if anyone ever did it that way. Either way around it is strictly less efficient than having the OS tell the drives which blocks to collect, and can cause data loss if the OS ever revs the volume format or uses an access pattern that the drive does not expect:

So it exists, and it is terrible. There are a whole of other problems:

1. It only ever worked with specific filesystems: generally NTFS, HFS+, and the various FAT based filesystems. Maybe some supported of ext2/3/4
2. It completely depended on the filesystem being used in a normal access pattern. Various LVM operations (like an offline repartition) might break those assumption in ways that can lead to data loss if the drive GCes while it is happening.
3. It is completely incompatible with any sort of full disk encryption like BitLocker or FileVault. This is an inherent limitation of the design since to perform active garbage collection the drive needs to read the filesystem structures, but with encrypted filesystems they keys and decryption are handled by the OS and the drive never sees the encrypted blocks. Sit there and wait in your boot loader as long as you want, it won't figure out and blocks to GC.

In practice it is just sitting there dormant and unused on any modern drives these (or hopefully everyone removed it from their controller firmwares after TRIM became prevalent). There are a few reasons for that:

1. Many more people use encrypted filesystems
2. Even people who don't tend use newer OSes which may have newer filesystems (or versions of filesystems) the drives don't understand. Most of these firmwares have to be super paranoid about volume format changes. And since the whole thing was a legacy hack that means that any OS with a new enough volume format change will also be new enough to support TRIM, which means vendors have little incentive to keep revving and incredibly complex piece of code that performs worse).
3. Some of the drives that did support AGC used explicit TRIM commands as a single to disable it, and all modern OSes issue TRIMs.

Back when TRIM was being standardized I had a 50+ page argument on an SSD vendors website where I was asking about the status TRIM in their chipsets. A whole bunch of enthusiasts essentially thought TRIM was unnecessary, and kept asking. It was super depressing because several people who had worked on filesystems, HDD firmwares, and storage controllers chimed in and tried to explain how there was simply no way for the drive to know what blocks were to safe to GC for arbitrary FSes and their implementations, and that TRIM was a necessary interfaces to channel the info from the drive to the OS. Unfortunately we were drowned out. by people who essentially kept asking "But how do you *KNOW* they have not designed a magic algorithm that knows about every volume format and the access pattern of every implementation of those formats and can magically decrypt everything to do GC correctly?" Clearly I found it scarring since I felt motivated to create an account here to post this ;-)