3 ms·
Curious - how does background GC eliminate the need for TRIM? I know it can use a set of unallocated blocks and clean them and swap them in and out where neces
by dedward 16y ago
Curious - how does background GC eliminate the need for TRIM?
I know it can use a set of unallocated blocks and clean them and swap them in and out where necessary - but without knowledge of the filesystem structure itself (TRIM) - it's always going to be sub-optimal. You'll have some fast write-space available, but not necessarily the full amount you could.
- stcredzero 16y agoMy understanding is that OS X/HFS+ already optimizes for reusing already allocated blocks. This means that fast write-space is conserved as much as possible at the expense of larger commit-loads from the OS's RAM cache when writing to already allocated blocks. Also, what I've read seems to indicate that OS X behaves sub-optimally, but this is still good enough to support snappy behavior under normal workloads.
- dedward 16y agoNot sure I follow.... the fast-write space in a non-TRIM device with GC is just some "extra" blocks (or whatever) that are kept aside and now and then swapped out for other in-use blocks (as far as the drive firmware is concerned - the OS has no idea this is going on) - and then the spare blocks are wiped for fast write again, then used when writes are requested. Really appreciate if you could shed any more light on why OSX would be better at this.. not sure I can picture this.
- stcredzero 16y agoOS X tries to avoid requesting "new" blocks for write. (AFAIK. Not an expert.)