DD.createAllDirectories will stop trying to create as soon as the first directory fails, so it's not going to be appropriate for generic FSWriteError handling. Suggest logging an error and explicitly shutting down instead. (This should only be called on startup.)
Looks like we should drop the "throws IOException" declaration from applyIndexUpdates (and have that chain throw FSWE as needed).
BatchCommitLogExecutorService.processWithSyncBatch should throw FSWE instead of RTE.
CommitLogSegment.sync should turn IOE into FSWE. Rest of sync heirarchy won't need throws declaration.
CASSANDRA-2118: will need to unwrap exceptions looking for FSWE since CLES/PCLES can wrap in ExecutionException. (Others might as well. Easier to do unwrap check in 2118 than to audit all possible executors.) On the other hand, this makes trying to catch the error before it hits the exception hook more of a pain, as in the next item...
CollationController needs to retain its try/catch, since we want to allow the read to succeed, even if the defragmenting write fails. Since it could error w/ either FSWE or EE (from the commitlog add), probably need to catch generic Exception. For 2118 we can add some way to submit this to the disk blacklister without re-throwing.
Looks like it would be worth adding a constructor for FSRW taking a Descriptor.
SSTR.createLinks should throw FSWE.
Methods called by SSTW constructor should throw FSWE.
SSTW methods should throw FSWE. (callers of append will want to catch + re-throw after cleanup.)
TruncateVerbHandler (and anyone else) shouldn't swallow potential FSWE by logging, need to rethrow. (FBUtilities.unchecked is handy in such cases.)
I agree with your use of AssertionError in LCR. Would prefer to use RTE in SSTableReader though, since we do some tricky reference counting around that and I wouldn't want to ignore problems there b/c someone turned off assertions. (Surprisingly common...)
SSTII should throw IOException when it doesn't know what DataInput is. Callers can transform to FSRE. (Other constructors, or in the last case, IncomingStreamReader.)
Corrupt sstables (sstablescanner + others?) shouldn't be turned into FSRE, since it's usually bad memory or a bug and not the disk's fault.
FileUtils should throw FSWE.
BTW: congratulations on getting import ordering (almost) correct on the first try. The only thing missing is, com.google.common goes above org.slf4j instead of being lumped in with "everything else."