On Monday 27 Oct 2014 13:13:00 Rich Freeman wrote: > On Mon, Oct 27, 2014 at 7:11 AM, Alan McKinnon <alan.mckin...@gmail.com> 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 -- Regards, Mick
signature.asc
Description: This is a digitally signed message part.
