The article seems kind of odd on some of its logic: >Its storage subsystem also has some surprising misses. Its rough version of LVM, LUKS, and md-raid is call

The article seems kind of odd on some of its logic: >Its storage subsystem also has some surprising misses. Its rough version of LVM, LUKS, and md-raid is called GEOM. GEOM, however, supports only RAID0, RAID1, and RAID3. It does not support RAID5 or RAID6 in software RAID configurations! Well, actually, it does support raid5, but also... With ZFS being a truly first class citizen, why not just use raid-z or zfs encryption instead of raid5 or luks? >ZFS also does not support some common operations, like adding a single disk to an existing RAID5 group (which is possible with md-raid and many other implementations.) This is a ZFS limitation on all platforms. No block pointer rewrite for ZFS, so no expanding of existing vdevs by adding disks, but you can still add more vdevs to increase the total pool size. You generally want specific numbers of disks based on raidz level for performance reasons anyway. (In general) RAID isn't really a "consumer" thing, outside of maybe a basic home NAS type environment. If you're doing this for a server environment where RAID sees the majority of it's use, I don't think it's too onerous to have to add more vdevs instead of a single disk. > Apparently this is because FreeBSD has nothing like Linux’s inotify. Nothing like? kqueue/kevent. It's not 'exactly' like inotify, but it's definitely something like it. (It's also something like epoll, and others... kqueue is fairly big and replaces multiple linux equivalents) I find it odd that the network stack isn't mentioned either. It's still significantly more performant than the linux network stack, and FreeBSD is pulling away even farther in this arena. Things like https://wiki.freebsd.org/NetworkRSS https://wiki.freebsd.org/NetworkRSS , netmap being a first class citizen, etc (Netflix blogs on why they chose FreeBSD for their CDN devices are fascinating) are all pretty damn sweet. Kind of nitpicky, I guess, especially since the author isn't claiming to be intimately familiar with the state of every part of modern FreeBSD