Catch up on stories from the past week (and beyond) at the Slashdot story archive


Forgot your password?
DEAL: For $25 - Add A Second Phone Number To Your Smartphone for life! Use promo code SLASHDOT25. Also, Slashdot's Facebook page has a chat bot now. Message it for stories and more. Check out the new SourceForge HTML5 internet speed test! ×

Comment Re:bit rot (Score 3, Informative) 475

Bit-rot is an issue inherent to any storage medium

Here's a quick article which explains how hard disks use error correcting codes so that the user-level experience is no bit rot but rather many many read failures before even a single block of undetectably corrupted data. Next time you can know what you're talking about.

Comment Re:bit rot (Score 4, Informative) 475

"ZFS isn't even a filesystem for this age" - WTF does that even mean?

It means that even back when FAT was a johnny come lately it already had greater market penetration than ZFS. With decades behind it and broad market penetration today, there's good reason to believe it won't vanish with the advent of the next development in filesystem architecture. ZFS is likely to be a blip on the radar, a pause before the next innovation. Not what you want for an archival format.

Bit-rot is an issue inherent to any storage medium

Bit rot, aka corrupted data, is not inherent to correctly operating hardware. As implemented, you'll see tens of thousands of unreadable blocks on a hard disk before you see a single one in which data has been undetectably corrupted. Every single sector gets a checksum in hardware and if the checksum does not pass you get the famous Abort Retry Ignore. For most storage you get Forward Error Correction coding so that some number of bit errors can be corrected on read before having to throw an error.

When you see bit rot, the storage media is usually not at fault. More often the data passes through faulty non-parity ram, a noisy memory bus or an overheated controller and gets corrupted on its way to storage rather than getting corrupted at rest on the storage. It died when you used an overclocked piece of garbage to copy it from an old hard disk to a newer, bigger one.

Comment Re:bit rot (Score 4, Informative) 475

He said a filesystem for the ages. While it has wonderful features, ZFS isn't even a filesystem for this age, let along ages to come. FAT32 and ISOFS are your best bets for being readable 20 years from now.

Bear in mind that your hard disk checksums each block and returns an error if the block is uncorrectable upon read rather than give you bad data. So, if you're getting bit rot at all then you have a hardware problem.

With or without a hardware problem you want to be able to recover your data. The answer is par2, such as parchive or QuickPar. Par2 uses a Reed-Solomon code to take a set of source files and produce a set of recovery files such that the original files can be checked for correctness and up to N original files can be corrected where N is the number of recovery files created.

And that's your answer. A filesystem like FAT32 or ISOFS that's likely to still be implemented in future OSes and a recovery files which let you rebuild anything that suffers from bit rot.

Comment Re: Perhaps a better method... (Score 1) 1001

Of course you use a binary search to find the insertion point. Then you move the latter half of the array to make room for the insertion. O(n^2).

If it's a linked list instead of an array, you get your insertion as a constant time operation but have to search half the list on average to find the insertion point. Still O(n^2).

Understanding your code's big-oh run time really is important.

Comment Re:Perhaps a better method... (Score 1) 1001

That's an eye chart. Asking someone to catch the greater than sign instead of a less than sign on paper in an interview is a downright nasty question. Of course people get tripped up on it. If it didn't catch my glance, I'd get tripped up on it and I've been programming for 30 years.

If you want to see how someone thinks through a problem, either give them a computer and watch or instruct them to "tell me what you'd do next to try to figure this out. I'll respond with the result you get each time you try."

Here's a better softball for computer science grads:

Your friend writes a program which receives messages. It adds each new message to a sorted array of messages. When a message is retrieved, it does a binary search on the sorted list to find the message.

What's wrong with this solution?

The candidate should be able to recognize that his "friend" has reinvented insertion sort and should be able to explain that the algorithm has a "big-oh" running time of O(n^2).

Slashdot Top Deals

When you are working hard, get up and retch every so often.