Am 08.01.2013 00:20, schrieb Alan McKinnon: > On Mon, 07 Jan 2013 21:11:35 +0100 > Florian Philipp <li...@binarywings.net> wrote: > >> Hi list! >> >> I have a use case where I am seriously concerned about bit rot [1] >> and I thought it might be a good idea to start looking for it in my >> own private stuff, too. [...] >> [1] http://en.wikipedia.org/wiki/Bit_rot >> >> Regards, >> Florian Philipp >> > > You are using a very peculiar definition of bitrot. > > "bits" do not "rot", they are not apples in a barrel. Bitrot usually > refers to code that goes unmaintained and no longer works in the system > it was installed. What definition are you using? >
That's why I referred to wikipedia, not the jargon file ;-) The definition that I thought about was decay of storage media, especially hard disks. I'm not aware of another commonly used name for that effect. Disk rot seems to apply only to optical media. > If you mean crummy code that goes unmaintained, then keep systems up to > date and report bugs. > > If you mean disk file corruption, then doing it file by file is a > colossal waste of time IMNSHO. You likely have >1,000,000 files. Are > you really going to md5sum each one daily? Really? > Well, not daily but often enough that I likely still have a valid copy as a backup. > This is a filesystem task, not a cronjab task. Use a filesystem that > does proper checksumming. ZFS does it, but that is of course somewhat > problematic on Linux. Check out the others, it will be something modern > you need, like ext4 maybe or btrfs > AFAIK, ext4 only has checksums for its metadata. Even if the file system would support appropriate checksums out-of-the-box, I'd still need a tool to regularly read files and report on errors. As I said above, the point is that I need to detect the error as long as I still have a valid backup. Professional archive solutions do this on their own but I'm looking for something suitable for desktop usage. Regards, Florian Philipp
signature.asc
Description: OpenPGP digital signature
