1 |
On Monday 27 Oct 2014 15:15:22 James wrote: |
2 |
> Rich Freeman <rich0 <at> gentoo.org> writes: |
3 |
> > > On 27/10/2014 11:24, Mick wrote: |
4 |
> > >>> With a caveat: if an ssd dies, it will die suddenly. Without warning. |
5 |
> |
6 |
> With SSD the most important fact to keep constantly in mind is |
7 |
> writing/erasing by blocks due to uniqueness of the hardware. |
8 |
> Unfortunately, if you dig deeply, many Solid State Storage devices |
9 |
> are organized differently and those hardware differences may impact |
10 |
> your SSD_specific implementation details. SSD raid redundancy is |
11 |
> something most machines (folks) cannot afford, imho and may be a waist |
12 |
> to dis_functional if you employ the same semantics for I/O on the |
13 |
> redundant SSD hardware. |
14 |
> |
15 |
> [1] |
16 |
> http://codecapsule.com/2014/02/12/coding-for-ssds-part-6-a-summary-what-eve |
17 |
> ry-programmer-should-know-about-solid-state-drives/ |
18 |
> |
19 |
> > >> In such cases I am prepared to live with the risk of some |
20 |
> > >> |
21 |
> > >> data loss, on machines where raid is not an option. |
22 |
> |
23 |
> Wise with a well thought out (planned) recovery/fresh-install strategy. |
24 |
> |
25 |
> > > Without some form of redundancy that would be your best strategy - |
26 |
> > > decent and frequent backups |
27 |
> > |
28 |
> > But yes, backup and RAID are really your only options for SSD failure |
29 |
> > as far as I can see it. That and limiting the amount of data that |
30 |
> > can't be re-generated. If you just save the world file and all of |
31 |
> > /etc you could probably rebuild a Gentoo install fairly quickly on a |
32 |
> > new drive, and then you're just left with /home and whatever else you |
33 |
> > happen to have installed that sticks stuff in /var that you care |
34 |
> > about. |
35 |
> |
36 |
> Yep. Rich has it exactly right. I'd add /usr/local/* |
37 |
> as by design that is where I put most uniqueness in any linux system |
38 |
> besides the list above. |
39 |
> |
40 |
> In fact for small networks, I just identify the directories that I want |
41 |
> to preserve. At the least you rsysnc those to a differnet system |
42 |
> on the local net, besides a backup, if no raid is underneath. (Triple). |
43 |
> Obviously, you have all systems on UPS power......? |
44 |
> |
45 |
> I'd add any dirs with custom scripts and the kernel files also minimally |
46 |
> replicated to another system. A comprehensive list of critical files |
47 |
> is fine. Workstations and servers have different lists of critial files; |
48 |
> and you can further subdivide the servers by function, to focus |
49 |
> on those critical files and directories. So what is on the SSD that is |
50 |
> important, just replicate it to a spinning HD on the local net. None |
51 |
> of this replaces weekly backups, but give you a tertiary level of |
52 |
> recovery redundancy for the important stuff. Triple redundancy is keenly |
53 |
> important for all critical stuff; ymmv. |
54 |
> |
55 |
> Personally, I find max-ram and spinning HD to be the best bang for the |
56 |
> buck. But, many folks with older portables are usually really happy with |
57 |
> SSD as a replacement (single) drive that is cost effective but needs |
58 |
> a network backup. |
59 |
> |
60 |
> [2] |
61 |
> http://serverfault.com/questions/454775/is-post-sudden-power-loss-filesyste |
62 |
> m-corruption-on-an-ssd-drives-ext3-partition |
63 |
> |
64 |
> |
65 |
> hth, |
66 |
> James |
67 |
|
68 |
Good comments and links James. Thank you. |
69 |
|
70 |
-- |
71 |
Regards, |
72 |
Mick |