When I had it running on my Windows 7 computer, I had the 64-bit installed first (since it was 64-bit Windows).  Since it was REALLY unstable (wouldn't go more than 12 hours without crashing, sometimes corrupting the database and redownloading the blockchain) I then loaded the 32-bit and made sure it loaded the old data files (which were working in the 64-bit version when I shut it down).  That worked solid, no problems for at least a month.

I kinda doubt there might be an issue with the files between 32 and 64 bit, at least for Windows anyway.  Maybe for Linux though.

When I set up the Fedora VM, I made it 32-bit from the start since I didn't want to mess with the stability issues like I saw with the Windows 64-bit version.  That install had been there for months, starting with the data files that the Windows box had (copied them over and replaced the contents of the Data folder in the linux install).

Hmm, this is odd.  Here's the three lines in debug.log from around when it happened:
2015-12-21 06:00:05 LevelDB read failure: IO error: /storage/Backups/bitcoin/data/chainstate/3047481.ldb: Permission denied
2015-12-21 06:00:05 IO error: /storage/Backups/bitcoin/data/chainstate/3047481.ldb: Permission denied
2015-12-21 14:06:29 Error reading from database: Database I/O error

Interesting that it doesn't record the error that is prompted until I clicked it this morning (just after 8am CST US time, which matches up to the last time stamp since that is UTC shown).

The line just before the LevelDB entry is from normal operation (lots of entries about the rate limiter kicking in on a free transaction).  Not sure why it thinks there is a permission denied issue, since immediately restarting the client works fine.

For reference, the /storage folder is a mount point for a software RAID5 array of four 2 TB drives, formatted EXT4. I've got others things (like a Windows VM running in Virtualbox) that have data files stored on that same volume, which were all working fine at the same time this happened.

I checked the kernel's messages log at midnight, matching up to that time stamp, and there's nothing odd listed.