1 |
On Monday 27 Oct 2014 13:13:00 Rich Freeman wrote: |
2 |
> On Mon, Oct 27, 2014 at 7:11 AM, Alan McKinnon <alan.mckinnon@×××××.com> |
3 |
wrote: |
4 |
> > On 27/10/2014 11:24, Mick wrote: |
5 |
> >> I'm starting a new thread so as to not hijack the one about alternative |
6 |
> >> kernels, but continue with something Volker raised. |
7 |
> >> |
8 |
> >> On Sunday 26 Oct 2014 23:25:50 Volker Armin Hemmann wrote: |
9 |
> >>> as others have written already: ssd. |
10 |
> >>> |
11 |
> >>> With a caveat: if an ssd dies, it will die suddenly. Without a warning. |
12 |
> >>> Usually 5 minutes before the start of your weekly or monthly backup |
13 |
> >>> run. And that is first hand experience. |
14 |
> >> |
15 |
> >> I haven't yet started using SSD and have wondered what sort of a system |
16 |
> >> should I set up to guard against such instantaneous catastrophic |
17 |
> >> failures. I am interested to hear what strategies people deploy to |
18 |
> >> avoid data loss with SSDs, especially on laptops that don't have the |
19 |
> >> luxury of raid redundancy. |
20 |
> >> |
21 |
> >> With spinning drives I use tar and rsync at regular intervals. There |
22 |
> >> have been a few rare cases where a drive failed without prior notice - |
23 |
> >> the last one after a reboot. In such cases I am prepared to live with |
24 |
> >> the risk of some data loss, on machines where raid is not an option. |
25 |
> > |
26 |
> > Without some form of redundancy that would be your best strategy - |
27 |
> > decent and frequent backups |
28 |
> |
29 |
> It isn't the most mature solution, but btrfs send has a lot of |
30 |
> potential here. One of the main costs of backups is the need to walk |
31 |
> all the data that you intend to backup to find changes. Rsync can do |
32 |
> wonders with minimizing bandwidth, and something like duplicity which |
33 |
> uses librsync can do wonders to minimize the size of serializing that |
34 |
> in files, but both require reading the entire filesystem. |
35 |
> |
36 |
> Btrfs send can serialize a set of changes in the filesystem by reading |
37 |
> only the btree nodes and extents that have changed. It is fairly |
38 |
> close to a git pull in that sense, though git doesn't use balanced |
39 |
> trees. That would greatly reduce the IO cost of frequent backups. |
40 |
> You would just periodically create a new snapshot, do a send between |
41 |
> the last snapshot and the new one, and once you've confirmed |
42 |
> successful completion of that you'd delete the old snapshot. |
43 |
> |
44 |
> Of course, IO seeks aren't nearly as expensive on an SSD as they are |
45 |
> on a hard drive. I haven't really done a lot of rsync on ssds while |
46 |
> using them so I can't really vouch for how much the IO impacts |
47 |
> operations. |
48 |
> |
49 |
> But yes, backup and RAID are really your only options for SSD failure |
50 |
> as far as I can see it. That and limiting the amount of data that |
51 |
> can't be re-generated. If you just save the world file and all of |
52 |
> /etc you could probably rebuild a Gentoo install fairly quickly on a |
53 |
> new drive, and then you're just left with /home and whatever else you |
54 |
> happen to have installed that sticks stuff in /var that you care |
55 |
> about. |
56 |
|
57 |
|
58 |
Thanks Rich, I have been reading your posts about btrfs with interest, but |
59 |
have not yet used it on my systems. Is btrfs agreeable with SSDs, or should I |
60 |
be using f2fs: |
61 |
|
62 |
http://www.phoronix.com/scan.php?page=article&item=linux_314_ssdfs&num=1 |
63 |
|
64 |
-- |
65 |
Regards, |
66 |
Mick |