If it’s the latter then I wonder what Apple (and Microsoft, and all the other big tech companies) do with their own internal file archives. To not do so is to essentiality throw up one’s hands and either say it’s too difficult a problem to solve (which isn’t true at all), or it just doesn’t matter. So in my opinion file integrity operations should be included in that category. And with the advance of technology and overall speed that becomes less and less of an issue. Yes, there is a noticeable hit when performing the first Spotlight index operation on a new, large volume, but it doesn’t lock out the user from doing anything else. Both use system resources and access the storage device(s) yet we still manage to use our computers just fine with those chugging away on their own. Regarding scheduled checksum generation and verification, we already have two examples (among many more) of similar background file-level operations: Time Machine and Spotlight indexing. My biggest complaint with Integrity Checker’s checksum process is it’s entirely manual, whereas I’d like to see something like what Vic (below) suggests – a scheduled background process. Again, a compromise, but I can’t think of any other way to do it given the file system constraints. And the folder-level checksum isn’t an all-or-nothing prospect in terms of updating: if you change a single file you can regenerate a new folder-level checksum using ‘Update’ which only looks at files that have changed (thus leaving all the rest alone and not re-hashing the entire folder). However storing the checksum of the folder’s contents in the folder itself, while a compromise, is the next best option. Regarding Integrity Checker, I agree that the checksum should ultimately be saved with the file itself, but then that brings this back into Apple’s domain and the file system itself. Howard, thank you for addressing this topic – as someone who still has original Mac files dating back to 1986 (when I got my first Mac SE) I have a personal interest in this topic. Jody Bruchon’s article arguing that most measures against bit rot are a waste of effort Wikipedia, a brief article which explains what can happen I’m thinking about that a great deal just now. That in turn requires a simple GUI method of scanning a volume and comparing each of the files with their expected checksum. Without much better information on risks and rates of bit rot in SSDs, it seems hard to justify imposing overhead on their performance just in case it might be significant.Ī better strategy for SSDs and write-only media such as archival Blu-ray disks is surely to monitor file checksums periodically, falling back to a copy of any file whose checksum changes. Hard disks are also among the poorer-performing media in widespread use, and the overhead of ECC and other safety measures could only worsen that. Few survive three years without developing some errors, so even if you replace them at that point, it’s likely that some repairs will have been necessary, or there will have been some data loss. One storage medium which should benefit most from a file system designed to detect bit rot and to self-correct using ECC is the hard disk. Even that is of little help if the medium is write-once, as is most likely in most archival storage. Much better are error-correcting codes (ECC), which can repair any error when it occurs, in a self-healing file system. This is in spite of three modern file systems – notably ZFS, Btrfs and ReFS – all incorporating methods designed to detect bit rot.ĭetecting bit rot in your sole copy of an important file isn’t particularly helpful either. That isn’t to say that it hasn’t been done, but if it has someone’s keeping very quiet about the results. When researching this article, I looked for contemporary measurements of bit rot rate on current storage media, and have been unable to find a robust scientific study which might yield such figures. If you can’t measure it, does it even exist? Look at most accounts and they’re full of sweeping assertions, technical descriptions of how bit rot might happen, but the only figures they’re ever likely to quote are drawn from manufacturers’ specifications or old studies on hard disks which are almost certainly irrelevant to modern storage media, even hard disks. But over what period is bit rot a significant risk? Are we talking months, years or centuries?īit rot and measures to protect from it are one of the most controversial topics in computing. In its broadest sense, this is data degradation, and is the result of imperfections in storage media. We all know that, over time, the documents and other data we store become gradually corrupted by ‘bit rot’.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |