On Tue, Feb 24, 2015 at 6:54 AM, Bob Wya <[email protected]> wrote: > I would always recommend a secure erase of an SSD - if you want a "fresh > start". That will mark all the NAND cells as clear of data. That will > benefit the longevity of your device / wear levelling.
Not a bad idea, though if you're trimming your filesystem (and it supports this), that shouldn't be necessary, and of course a log-based filesystem like f2fs should promote excellent wear leveling automatically by design. Granted, that doesn't help you if an f2fs bug eats your data. > Personally having been burned by btrfs I would not try one of these > "experimental" file systems again... Well, trying them is one thing, relying on them is something else. I've had a few issues with btrfs in the last year but they've all been of the uptime/availability nature and none has actually caused unrecoverable data loss. It has caused me to start moving back towards the longterm stable branch though as the level of regressions has been fairly high of late. However, right now I keep everything on btrfs backed up onto ext4 using rsnapshot daily (an rsync-based tool I recommend if you're the sort that likes rsync for backups). So, the impact of a total filesystem failure is limited to availability (granted, quite a bit of it to completely restore multiple TB). That risk is acceptable for what I'm using it for. Another risk would be a silent corruption that persists longer than the number of backups I retain, but I think that is unlikely since silent failures is one of those things btrfs is designed to be good at detecting/preventing, and I've yet to see any reports of this kind of failure which makes me tend to think that if anything there is more risk of a silent corruption impacting my backups (ie I'm contrasting the risk of btrfs quietly storing the wrong content of a file vs the risk of a hard drive bit flip messing up data which ext4 can't detect). In general though there is a reason that sysadmins tend to be very conservative with filesystems. I doubt most even jumped onto ext4 all that quickly even though that was very stable from the start of being declared as such. You really need to look at your use case and understand the risks and benefits and how you plan to mitigate the risks. Something being experimental isn't a reason to automatically avoid using it if it brings some significant benefit to your design, as long as you've mitigated the risks. And, of course, if your goal is to better understand an experimental technology in a non-critical setting you should probably just get your feet wet. However, what you shouldn't do is just pick an experimental anything as a go-to default for something you want to never have to fuss with. -- Rich
