NTFS doesn't have a 255 character limit on paths. The default file handler API in Windows (even 7/2008) is limited to ~254 characters. You can force force the use of the newer API (with 32K path lengths) by using \\?\, but I've personally found application support to be spotty, even under MS applications.

Specifics available here:
http://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).aspx

Wow, I sorta feel like an idiot for missing that. I hadn't given it a lot of thought, but I'd just sort of assumed that the hobbits possessed some natural magical resistance to the ring. Now that I see you point it out, it's so obvious that it hurts. It also clears up why Bombadil is in there, which is otherwise a very odd and short subplot.

Seriously? What is with the lack of recognition? Say what you will about his writing style (I never could make it through The Silmarillion), but the man basically defined characteristics and styles of fantasy species for every book afterwards. He based his work on preexisting mythos, but he consolidated a lot of opposing mythos and people have been using what he defined ever since.

Tolkien probably had a bigger impact on fantasy writing than any else, before or after.

That sounds like mass memorization combined with social engineering. A difficult feat, but something very different from logic puzzles.

In my extremely limited experience talking to lawyers, it seems like law firms typically use a team of people with different skill sets. People to examine past case law for relevant information, people to compile relevant information in a useful way, and people to present the information in a convincing manner.

I'm having a hard time imagining why you're using 320 bytes for each block. If you had a 100TB of data in 4KB blocks, that's 25 billion blocks. You could use an on-disk reference table for pointing out duplicate blocks and reference it with 36 bits. If you used an excessive 256 bit hashing algorithm for each block, a b-tree with two 64-bit spaces for references, and a 4 control bits, that still only gets you to 420 bits, which is 53 bytes. You only need to store location information for blocks that are actually deduped in RAM (the rest is only referenced when a dedupe happens), so two 36 bit locations on a duplicate block would bring the total for a duplicate block to 62 bytes, with an additional ~5 bytes for each additional block that is found to be a duplicate.

Let's say it's 50TB duplicated exactly, for a total of 100TB. 5*10^13/4KB*62B = 775GB. That's a lot of RAM, but it's still only 0.7% of the total. And you could get far more efficient by using a smaller hash with a reference to a larger on-disk hash table. A 32 bit hash with a 35 bit on-disk reference (containing disk block locations and longer hashes), a b-tree with two 35 bit memory offsets, plus 20 bits for whatever, and you'd be at 24 bytes, which would drop your total memory usage to 300GB.

Of course, 32 bytes would align much better, and you could decrease space to 1/16th by using 64KB block sizes, but the point is that 320 bytes is clearly absurd. All I can think of is that you should be typing bits instead of bytes.

Our online backups for databases are primarily snapshots of the volumes that host the databases. Because of dedupe + snapshots, the space and time for the online backups are negligible. If I have to restore the database to yesterday, we stop the service, restore the volume to a snapshot (a few seconds), and start the service. The space used for offline backups certainly isn't efficient, but that's much cheaper storage so it doesn't matter.

It's probably heavily dependent on the content, types of disks, and number of disks. With a few spinning disks where multiple large files are typically streamed sequentially, adding 10% randomness would be a pretty severe penalty. An SSD has essentially zero negative effect from randomness though, so they would probably benefit greatly.

It's worth pointing out that many modern SSDs actually perform compression on their storage internally to increase performance.

Indeed. We use Netapps for our VMs, which have built in dedupe. But log files won't dedupe, so using compression on directories that store logs is an easy way to save space. It's also an easy way to keep from having to expand the disk size, and to keep log directories under control that can grow rapidly.

I went to a week of training recently that was hosted in my city, so I just drove instead of staying in hotels like everyone else. The office the training was located in was downtown near the top of a sky scraper, with a great view. It was a serious pain to deal with traffic and parking every day, not to mention the wireless was over loaded and the facilities were small. The companies actual main offices were located in a really nice green belt area right off a freeway, and would have been a cinch to get to. When asked, the only reason for using the skyscraper was prestige to impress the people taking the class.

I wasn't impressed.

I'm also quite pleased with Tree Style Tabs. When I'm researching something, I can have dozens of tabs open and organized by how I got to each one. No other browser can have as many tabs and be even remotely useful for finding them.