UFS UFS on SSD

I have experience using UFS on both HDD and SSD. I can say that after using the SSD, the speed of the system increased significantly.
 
FreeBSD has full support for UFS on SSDs. You would typically create a file system with newfs -t -U, which turns on TRIM and soft updates.

You can turn TRIM on and off with tunefs -t enable|disable. And you can trim the free list on a file system with fsck_ffs -E.

I have not used UFS on FreeBSD for some time, and I'm not sure if TRIM gets turned on automatically if you install onto an SSD. It's easy to check with tunefs -p.

I am not aware of any specific facility to TRIM an on-line file system periodically (e.g. weekly from cron) with the equivalent of the Linux fstrim command.
 
There is SSDFS on other platforms (if that is what you are referring to).

But "not completely stable" yet; just like most Linux technologies.

UFS and FreeBSD's implementation of ZFS are pretty rock solid. That characteristic is pretty much an "optimisation", these days.
 
I like to keep atimes on. It is useful to debug things, it answers questions such as "did that crashing application make it to reading its dotfiles?".

%%

Are there any benchmarks out there for more SSD-oriented filesystems? I am not convinced that this is particularly effective since the SSDs themselves are engineered to the max to perform optimally with conventional filesystems. There is a lot of software running on a complicated controller there. I can see how Flash (as in USB sticks) oriented filesystems are a huge advantage, but SSD I would like to see data.

The situation is different on e.g. a Mac, which I hear has a more "raw" SSD and some of the logic for managing it has been moved into macOS. Needless to say that is hard to verify. I guess we will learn about it when more Linux and FreeBSD installs run on Apple Silicon and either blow up the SSDs or not.
 
All the SSDs I know of have some sort of SATA interface, so a translation/emulation layer to the physical devices, pretending to be spinning disks. TRIM is about the biggest optimization I'm aware of (SSDs, erase is what kills the device typically) That translation layer hides a lot of the SSD specifics from the rest of the system.

Now at the physical layer, where the data is actually stored, there isn't a lot difference between SSD and NVme; the big difference is above the physical. That's why FreeBSD has a nvme device driver which basically has no SATA translation layer.

So, my opinion only, UFS works fine on SSDs, there isn't really a lot to "Optimize" at the UFS level except for TRIM, one may or may not want to disable atime on specific partitions. I personally would not want a "filesystem" optimized for a specific type of storage device. Filesystem should be device agnostic, a device driver exposing something a filesystem can use or an intermediate layer (VFS) is where any optimization should occur (My opinon only, feel free to disagree)
 
I think it's possible to argue that UFS TRIM could be improved on FreeBSD.

I have several Linux systems using SSDs. None of them have TRIM enabled at the file system level. They do have it enabled at the volume manager level, but only for TRIMing disk blocks explicitly released by the volume manager itself (e.g. when a volume is shrunk).

I TRIM all my Linux SSD file systems weekly, from cron, using fstrim. The TRIM request has to percolate through several software layers. In my case, that's almost always xfs (file system), lvm (volume manager), md (software RAID), and hardware (SATA). But fstrim works regardless of the stack (well, for all the common file system options).

Enabling TRIM at the file system level means that TRIM is activated every time a file is deleted (blocks get added to the free list) which:
  • presents large numbers of small chunks of free disk blocks to the SSD controller, fragmenting the lists; and
  • routinely disrupts and slows down regular file system activities.
Conversely, periodic bulk TRIMing facilitates the aggregation of maximal length runs of free blocks for presentation to the SSD controller, shortening the lists and minimising fragmentation. It also limits I/O disruption from TRIM commands to a time of the administrators' choosing.

Bulk TRIMing does need to be scheduled at a quiet time, as it's significantly disruptive to other file system activity.
 
My opinions only.

gpw928 the Linux volume manager level sounds similar to how TRIM is integrated with ZFS (since ZFS can be considered a combination of filesystem and volume manager), fstrim sounds to me "expose the TRIM command to the user level".
I'm not saying this is good or bad, just my opinion on "what it sounds like".

gpw928 said:
Enabling TRIM at the file system level means that TRIM is activated every time a file is deleted
Click to expand...
I think it may be more accurate to say "TRIM may be activated every time a file is deleted". I think of it as akin to garbage collection in memory management. "Mark stuff as in need of a TRIM, actually do the operation sometime in the future".
Now it may be more efficient/better for the device if TRIMs for all UFS filesystems on a specific device are grouped together and done at the same time, almost sounds like a GEOM class that sits below the UFS or partition but above the physical device. As for fstrim type of operations, sounds like an extension to fsck or something.
As for bulk TRIM at quiet time, kind of like zpool scrub.
 
ZFS, UFS, and various Linux file systems all have pretty similar options for enabling discards (automatic TRIMing) from within the file system code, and also for bulk TRIMing the free list.

The exact mechanisms, and optimisations, used to enable automatic discards within the file system code are "implementation dependant". However I believe that discards are usually done in the file system code when disk blocks are returned to the free list.

UFS file systems can be bulk TRIM'd with fsck -E. However, I have never been able to figure out if this is the intended mechanism to perform routine on-line bulk TRIMing (without risking the fsck doing anything else).
 
  • Like
Reactions: mer
You must log in or register to reply here.
Back
Top