1 |
Am Dienstag, 8. Januar 2013, 08:27:51 schrieb Florian Philipp: |
2 |
> Am 08.01.2013 00:20, schrieb Alan McKinnon: |
3 |
> > On Mon, 07 Jan 2013 21:11:35 +0100 |
4 |
> > |
5 |
> > Florian Philipp <lists@×××××××××××.net> wrote: |
6 |
> >> Hi list! |
7 |
> >> |
8 |
> >> I have a use case where I am seriously concerned about bit rot [1] |
9 |
> >> and I thought it might be a good idea to start looking for it in my |
10 |
> >> own private stuff, too. |
11 |
> |
12 |
> [...] |
13 |
> |
14 |
> >> [1] http://en.wikipedia.org/wiki/Bit_rot |
15 |
> >> |
16 |
> >> Regards, |
17 |
> >> Florian Philipp |
18 |
> > |
19 |
> > You are using a very peculiar definition of bitrot. |
20 |
> > |
21 |
> > "bits" do not "rot", they are not apples in a barrel. Bitrot usually |
22 |
> > refers to code that goes unmaintained and no longer works in the system |
23 |
> > it was installed. What definition are you using? |
24 |
> |
25 |
> That's why I referred to wikipedia, not the jargon file ;-) |
26 |
> |
27 |
> The definition that I thought about was decay of storage media, |
28 |
> especially hard disks. I'm not aware of another commonly used name for |
29 |
> that effect. Disk rot seems to apply only to optical media. |
30 |
> |
31 |
> > If you mean crummy code that goes unmaintained, then keep systems up to |
32 |
> > date and report bugs. |
33 |
> > |
34 |
> > If you mean disk file corruption, then doing it file by file is a |
35 |
> > colossal waste of time IMNSHO. You likely have >1,000,000 files. Are |
36 |
> > you really going to md5sum each one daily? Really? |
37 |
> |
38 |
> Well, not daily but often enough that I likely still have a valid copy |
39 |
> as a backup. |
40 |
|
41 |
and who guarantees that the backup is the correct file? |
42 |
|
43 |
btw, the solution is zfs and weekly scrub runs. |
44 |
|
45 |
-- |
46 |
#163933 |