Am 27.10.2014 um 16:22 schrieb Mick: > On Monday 27 Oct 2014 13:13:00 Rich Freeman wrote: >> On Mon, Oct 27, 2014 at 7:11 AM, Alan McKinnon <[email protected]> > wrote: >>> On 27/10/2014 11:24, Mick wrote: >>>> I'm starting a new thread so as to not hijack the one about alternative >>>> kernels, but continue with something Volker raised. >>>> >>>> On Sunday 26 Oct 2014 23:25:50 Volker Armin Hemmann wrote: >>>>> as others have written already: ssd. >>>>> >>>>> With a caveat: if an ssd dies, it will die suddenly. Without a warning. >>>>> Usually 5 minutes before the start of your weekly or monthly backup >>>>> run. And that is first hand experience. >>>> I haven't yet started using SSD and have wondered what sort of a system >>>> should I set up to guard against such instantaneous catastrophic >>>> failures. I am interested to hear what strategies people deploy to >>>> avoid data loss with SSDs, especially on laptops that don't have the >>>> luxury of raid redundancy. >>>> >>>> With spinning drives I use tar and rsync at regular intervals. There >>>> have been a few rare cases where a drive failed without prior notice - >>>> the last one after a reboot. In such cases I am prepared to live with >>>> the risk of some data loss, on machines where raid is not an option. >>> Without some form of redundancy that would be your best strategy - >>> decent and frequent backups >> It isn't the most mature solution, but btrfs send has a lot of >> potential here. One of the main costs of backups is the need to walk >> all the data that you intend to backup to find changes. Rsync can do >> wonders with minimizing bandwidth, and something like duplicity which >> uses librsync can do wonders to minimize the size of serializing that >> in files, but both require reading the entire filesystem. >> >> Btrfs send can serialize a set of changes in the filesystem by reading >> only the btree nodes and extents that have changed. It is fairly >> close to a git pull in that sense, though git doesn't use balanced >> trees. That would greatly reduce the IO cost of frequent backups. >> You would just periodically create a new snapshot, do a send between >> the last snapshot and the new one, and once you've confirmed >> successful completion of that you'd delete the old snapshot. >> >> Of course, IO seeks aren't nearly as expensive on an SSD as they are >> on a hard drive. I haven't really done a lot of rsync on ssds while >> using them so I can't really vouch for how much the IO impacts >> operations. >> >> But yes, backup and RAID are really your only options for SSD failure >> as far as I can see it. That and limiting the amount of data that >> can't be re-generated. If you just save the world file and all of >> /etc you could probably rebuild a Gentoo install fairly quickly on a >> new drive, and then you're just left with /home and whatever else you >> happen to have installed that sticks stuff in /var that you care >> about. > > Thanks Rich, I have been reading your posts about btrfs with interest, but > have not yet used it on my systems. Is btrfs agreeable with SSDs, or should > I > be using f2fs: > > http://www.phoronix.com/scan.php?page=article&item=linux_314_ssdfs&num=1 >
neither. Just use ext4. You don't want to combine the sensitive nature of a ssd with the youthful playfulness of a young filesystem. Also, I am a little bit concerned about that 'freshly formatted' at the start of the article.
