Slashdot Mirror
File Systems Best Suited for Archival Storage?
Amir Ansari asks: "There have been many comparisons between various archival media (hard drive, tape, magneto-optical, CD/DVD, and so on). Of course, the most important characteristics are permanence and portability, but what about the file systems involved? For instance, I routinely archive my data onto an external hard drive: easy to update and mirror, but which file system provides the best combination of reliability, future-proofing, data recovery, and availability across multiple platforms (Linux, OS X, BeOS/Zeta and Windows, in my case)? Open Source best guarantees the future availability of the standard and specification, but are file systems such as ext2 suitable for archival storage? Is journaling important?"
If you are not constantly editing the information (and you won't be, it's for archival purposes) the admittedly major downsides of not being journalled and being prone to fragmentation are non-issues. You might run into problem with capacity limits and/or file size limits though.
Pathman, Free (as in GPL) 3D Pac Man
Of course, that's just my opinion--then again, I could be wrong.
"Care about people's opinions and you will be their prisoner." ~~Tao Te Ching~~
I would say that ubiquity is the most important factor in being able to read something in the future, not it being open source. FAT32 is certain to be easily, if not legally, accessible for the very short expected lifetime of an external harddrive. To improve data recovery capabilities, you might like to create some archives in RAR format for error checking, with PAR2 files for redundancy and recovery. Hard drive space is cheap, so for safety keep the uncompressed files as well as the archives. Since hard drives fail, you should have more than one of them. And ideally, make DVDs also. I created some files with early betas of Openoffice 2, and it was not at all easy to open them once the file format changed before the final release. As another example, despite it being open source, the legal problems of Reiser may cause that file system to be inconvenient to access in the future. An outdated, but very popular legacy format will have support that will last far longer than people want it to. Because of the high marketshare that Wordperfect had in the days of Noah, even now you can open Wordperfect files in Word and Openoffice. If you think FAT32 will be unreadable anytime soon, think again.
Is this going to be relatively live, with data being mirrored onto it regularly, or is this going to be written once and accessed occasionally from then on? If you're only going to write to it a very small portion of the time, (or even WORM), journaling will be useless to you, since anything that takes out your data won't be stopped by it.
How far into the future are you going to need it? I understand the whole "not wanting to become unreadble," but honestly, no one's going to bother re-implementing a filesystem to look at their old vacation photos. Pick a popular filesystem, and you'll be sure of support down the line. FAT's still doing just fine for itself, and the ISO filesystems for CDs and DVDs will be readable as long as people are making drives for them.
All of the data integrity features on filesystems aren't going to protect against disk failure/media wearing out, and error correction on that scale is beyond the scope of any one disk to handle. Like the department jokingly advised, parity files and other methods can handle this in a robust, media-spanning manner, and protect against everything from a few flipped bits to a whole-disk data loss (assuming you have enough parity data).
I think the reason not much talk about filesystems has been going on is because they're mostly irrelevant for this task. They're designed to handle the issues of a live environment; the issues that archives face are beyond the capability of how you choose to store your data on each piece of media to solve.
Remember, there were no nuclear weapons before women were allowed to vote.
If you're only using it for archive, writing anew each time, then skip the file system altogether. Treat the media like a block device, tar or otherwise archive your backup and just write the tar as a single, linear sequence of bytes. And don't compress it, so that a bit error early in the sequence doesn't mess up later blocks.
Now which archive format is best - tar, cpio, etc.? I've heard that cpio is a much simpler underlying format.
And if you have the space, write the archive sequence multiple times onto the block device, so if one block is destroyed you can pick it from from a peer location.
-Jeff
I don't know how to tell you this, but you're an idiot.
"There have been many comparisons between various archival media". ARCHIVAL is the key word. As in "we don't move these files around a lot". As in "It doesn't make much sense as an end user to discuss the undelying filesystem to something which is used to just have files sit around, as long as it's stable". Buy something that has dedicated commercial support for the next 20-40 years, like the LTO standard and call me in the morning.
----
There is really no best file system for every purpose.
Since you want reliability and portability, I recommend DVD+Rs. They are certainly more reliable than an external hard drive, and more portable too.
It really depends on how you use your archive. Since you carry your archive around, I would recommend against an external hard drive since they can be quite fragile.
Your file system choice depends a lot on the storage technology choice. Of course for the previously mentioned, 9660 would meet your needs the best: "reliability, future-proofing, data recovery, and availability across multiple platforms". Your going to be able to find a DVD writer for a while to come. Furthermore, there are very minimal DVD incompatibilities across the platforms.
Like I said, application matters a lot. If your using hard drives, then what your storing can have a big effect on which file system you should use. For example, if you require stationary backup of very large files on a UNIX OS, then it benefits you to store the information using JFS or another large file efficient file system. Your not going to want to change the file system once you've stored everything on it, and since a certain file system was more efficient to store the information with in the first place, then its more effective to keep it in that format for the long term.
File systems depend on the storage technology they are used with, and the utility of a file system depends on how you use it.
I've been wondering lately why no common file systems seem to implement error correcting codes (ECC/EDAC).
...
In hardware, there's often a checksum, ECC/Hamming code, parity bit, Reed-Solomon code, etc. to detect and/or correct for inadvertent bit flips. But, as far as I know, no error correcting information is ever stored within the filesystem itself. Certainly the filesystem tracks how many blocks are dedicated to a particular file, and how many bytes long the file is, and one can always hash the file twelve ways to Sunday to assure that it hasn't changed since it was originally hashed, but none of that helps repair errors to the file should the medium that's being used to store it decay beyond what's already correctable via the medium access hardware.
I can imagine scenarios where, for example, the RAM buffer in a hard drive is upset and perfectly encodes the wrong bit into a file (or even multiple stripes + parity in a RAID). In this case, the medium access hardware is useless (the data was, after all, ecoded perfectly wrong), but ECC in the filesystem would detect and potentially correct the error the next time the file was read back, even if it were decades later. I appreciate that it would add overhead, and thus maybe shouldn't be the default, but I don't see it being even an option anywhere, and some people would pay the performance penalty to get the data integrity benefit.
Especially in instances like encrypted (or compressed, or both) loopback file systems where one bad bit can destroy an entire partition, why don't we have more data assurance layers available? Or have I just not found them?
Whining of which, what was the deal with GNU ecc? Everyone speaks of "oh, yeah, the algorithm was deeply flawed, bummer..." but I don't ever see any details
In one form or another anyway. People keep asking about the _best_ way to store data for a long time (for some definition of best)
My take on this problem is that you should use the best you reasonably can today. Then in 5 years time when there is a new technology out there, move over to that for archiveing your new data AND move your old data over while you still have working hardware.
I went from floppy disks to LS-120 drives. From LS-120 drives to CDs. From CDs to DVDs. I'll go from DVDs to whichever of HD or BD seems best in a couple of years (unless something else crops up). I might use hard drives instead but I'm not sure yet. The point is I don't need to decide until I need to store that much.
If you're playing in the big leagues do the same with the various formats of giganto capacity tape storage etc.
Plan around the shelf-life and working life of the hardware you can get and the answer drops out.
Ext2 fs mounted rw,sync. When just reading, or just writing, async can't possibly help performance. You're strictly limited by disk I/O. Async will, however, cause irrecoverable corruption if there's a system crash or power failure, which was a source of great frustration with Linux before the journaling filesystems came along.
Ext2 can be read by nearly even operating system out there, and doesn't have the numerous limitations of FAT32.
Which, incidentally, is the exact same answer I gave a few months ago, when the last guy wrote an Ask Slashdot to ask the exact same question...
Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
If you leave a drive in a closet for 10 years, will it still spin up?
The best file system for archival purposes is the one you're using today. Why? Because of you want that archive to be readable in any expedient manner, you are going to have to constantly monitor and update the media on which it is stored. All media will degrade over time, and you will have no idea how bad that degradation has been until you re-read it. No vendor will compensate you for the loss of your data, because there is some data which simply cannot be recreated.
If you want archival storage, you need to have your data on- or near-line, and rewrite the data to the "new" hardware every couple of years. By choosing a filesystem that is current, you are more likely to be cable to read it in a couple years than if you (try to) stick with a single filesystem. I know this sounds like a lot of work, but if the data is truly worth archiving, it's worth keeping both the storage mechanism and format up to date.
Is it just my observation, or are there way too many stupid people in the world?
Thanks to the emulation community, I can read data from an old Commodore 64, Apple ][e, Atari, etc. on any modern computer running any mainstream operating system. What I cannot do is easily hook up an old Apple ][e disk drive to my modern hardware very easily. The filesystem will not really matter so much, because even if Wintel goes the way of the Commodore 64, someone will make a DOSBOX-esque emulator for it. Getting data off of an ATA, SATA, USB, or Firewire drive might be more challenging once new hardware ceases to support those standards.
Personally, I just throw stuff on external hard drives. 3-5 years later, the new drives are so much bigger, faster, and cheaper that it becomes economical to consolidate to a new drive. I still have data from a 286 that had nothing but floppies, an Apple ][e, and 2 dead Macintoshes. Even my old Windows 95 computer lives on as a VirtualPC image. I don't really use them that much, but the Apple ][e and 286 stuff is under 50 megs, and the VirtualPC image is 2GB. The images of the old Mac hard drives total less than 1GB... it's simply not worth deleting them and it's kind of fun to have my old computers still around, if only "virtually".
W..w..W - Willy Waterloo washes Warren Wiggins who is washing Waldo Woo.
Ext2 is suitable, because it is very likely to have really long-term support. And as long as you can boot Linux and copy the files over to some other filesystem, that is enough. Of coruse there may come a time when Linux drops backwards compatibility, but considering that the 2.0 Kernels are still supported, can run on current hardware and all kernels are still available, I would say this will not be anytime soon. Same for FAT through Linux. It is not going away, and since it is not under development, maintaining the code is very little effort.
As archiver, I would recomend GNU tar, which (AFAIK) still supports every format it could ever create in its (long) history. Compression by either gzip (if you are not concerned about bit-errors) or better bzip2. Both compile on with C compilers. Both are used for archiving Linux kernels, so I expect they do have long-term support as well. And both have been stable for a significant time now.
Journalling is not needed for archiving at all. It is a feature designed to give better remount times after crashes.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
I use ext3 on my external backup disks because:
- it is much better and more reliable than FAT32
- it is both open source and (relatively) widely used, so I expect there will always be some way to read it
- it can easily be read by attaching it to any machine and booting some Linux LiveCD or bootable USB.
- the OS which traditionally can read ext2/3 is itself open source and also widely used, so there is no fear that it would become unavailable
For archival and backup, I feel all these advantages far outweigh the slight inconvenience that the disks are not readable directly by Windows and Mac, requiring either a driver or a reboot into Linux.
The important point is to label the disks very clearly. Otherwise, someone connecting them to a Windows or Mac machine may believe the disk is empty and re-partition/re-format it! I would not only put a big explanatory label on the disk's case, but also name the volume something like "Linux-..." or "Linux-ext3-...", and also explain to persons involved (manager(s) + people handling the disks) that they are not readable in Windows (some people don't read even big labels...).
I use Ext3 for my backup drive, and this driver for when I need to attach it to a Windows box.
Buy something that has dedicated commercial support for the next 20-40 years
You mean like DEC or any of the other out-of-business dinosaurs?
As someone who has been through this, I can only say: do NOT buy anything that depends on "dedicated commercial support"; the companies and industry standards you think are going to be around for "20-40 years" are probably either not going to be, or they are not going to give a damn about you.
Use open standards and open formats, with multi-vendor support; that's the only way to go. And you need to keep your eyes open and move to new formats and standards as the world changes.
If LTO is the right choice, it's the right choice because of that. But I'm not convinced that LTO is going to be long-lived enough as a standard, no matter how many companies have tied their fortunes to it right now.
Tar.
Here's why: IMO, unless you're doing it for a company, the most important thing is convenience.
If it's your job, sure, you'll do it whether it's convenient or not.
If it isn't, you'll quickly get tired of messing with CDs, plugging/unplugging hard drives, etc. So I went with the most convenient media possible: tape. Stick a tape into the drive, walk away, store when it spits it out. It doesn't interfere with the computer's usage since nothing else uses tape.
For absolute convenience, get a tape robot from ebay. Then it can be completely automatic.
Filesystem: use plain tar to write to the tape. If you must use compression, compress files individually, not the whole tape.
Paranoid implementation: Tapes have file marks. You can ask the tape drive to give you file #1 for instance. You can use this to store some useful stuff in a format that will always be recoverable so long you have a drive that can read the tape. Store like this:
File 1: Text document explaining what's all this stuff, and what's on the tape.
File 2: RFC for tar format
File 3: RFC for compression format
File 4: source for tar program
File 5: source for decompression program
File 6: backup
A tape formatted like this should be readable so long a drive capable of reading the data in it survives. To ensure that, go with a popular tape format, which is reliable, open, and has a high capacity (so that it's unlikely to become obsolete too fast)
I don't know how to tell you this, but you're a jerk.
(Or you're at least acting like one right now.)
Admittedly this is not a brilliant question -- If the guy is at all savvy, it should be obvious with a moment's reflection that journaling and fragmentation are non-issues for an archival filesystem. But the reason he's asking is because he's not savvy on this topic. Is that okay with you? I have as little patience as any of us when it comes to idiot users, but aside from not knowing a lot about filesystems there's no evidence that this guy is an idiot. He looks to me like a newbie trying to be responsible and better himself. Oh, how I wish my lusers could be more like that!
Despite it not being a *great* question, it's still a reasonable one, for which there are good answers and bad answers. FAT and ISO9660 are examples of good answers because they are straightforward, well-documented, without irrelevant features for the task at hand, and both have 20-something years of ubiquity behind them and are still very much alive and kicking -- they will be supported on all platforms long into the foreseeable future.
You mention the LTO standard, and maybe that's a good answer too, but I don't know because you don't explain what it is or give any pointers to additional information. Do you really expect that answer to helpful to the guy asking the question? (I found what I *think* you're talking about on Wikipedia, no thanks to you, and it doesn't look very relevant to the original poster's question.)
The guys over at Bell Labs developed Venti as a part of their Plan9 Operating System. If you are not adventurous enough to install Plan9, they have a great set of ports called Plan9 Port that has most of the exciting bits of Plan9 for other *nix like Operating Systems including Linux and Max OS X. Venti is an archival storage server, utilities and filesystem. It works with both magnetic and optical media.
TECMATIC - Intelligent Technology News
While not as widely used (yet), it will eventually become the de-facto standard in safe filesystems.
I've thrown all kinds of problems at it, and it has yet to lose a single byte of data.
Add to that, taking snapshots every (x) minutes, you can look back in time as easily as reading a folder.
With RAIDZ2 in the latest releases, you can set up sets that can withstand the loss of 2 physical drives. If you couple multiple RAIDZ2 sets into a single pool, you've increased the redundancy even further. With plain old JBOD and multiple controllers, you can reach levels of availability that only expensive EMC/Hitachi/StorEdge systems have reached in the past.
It's opensource as well (although it's the Sun flavor at this time), and being worked on at www.opensolaris.org. I believe Sun is contemplating switching it to GPL at this time.
Who is general failure, and why is he reading my hard drive?
What appears to have been established here is that electronic storage media does not last for long (compared with, as mentioned in previous comments, written text or stone engravings), irrespective of the filesystem used on that media. Therefore perhaps a single archive copy is not enough. What about a distributed system such as LOCKSS http://www.lockss.org/lockss/Home would be better for archive storage as it essentially abstracts the hardwaee and filesystems that the data is stored on.
Do you need data-readback in a matter of seconds? Minutes? hours? days?
Do you need storage for years, decades, centuries, millennia, 10,000 years, or longer?
Do you need an indexing system based on content or just on title/filename?
Can the data be printed out or carved into stone without losing important information?
Is this a go-to-jail-if-you-don't legal requirement, a may-go-bankrupt-if-you-don't business requirement, or a save-us-a-bunch-of-money-nice-thing-to-have requirement?
Do you think the cost of researching the "best" solution worth the improvement over the 2nd- or 3rd-best solution?
Let's assume you need it for 50 years, access is infrequent, and you can wait 24 hours for data recovery. Talk to the folks at Iron Mountain and other data-retention warehouses, they are experts in the field and will be happy to consult with you or do the entire job turn-key.
My hunch:
For most applications involving less than 50 year data retention, making 2 copies of the raw data, to a currently supported stable media such as tape or archival DVD, stored in separate locations, is key. Make sure the data is both in the original format and in a published-standard format which is widely supported.
Keep multiple machines that can read the data around for as long as you need the original format. Every few years or as needed, verify the data is intact, re-convert the data from the original format or, if that format is unreadable, the highest-fidelity published-standard format, to a currently-supported published standard, and save it to a currently-supported archival format.
Ideally, in 50 years time, you will have the original media plus several updated copies. You may or may not be able to read the original media but your most recent copies will be close enough to the original to be useful. If you are very lucky, the most recent copies will be identical to the originals AND you will still have the software and hardware to read them.
Oh, for anything REALLY important, print it out on archival paper, or carve it into stone.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
What you read about is a matrix code (no, not backwards kana). 4 pixels per mm times 25.4 mm per inch = 100 dpi. Olympus Dot Code, used by Nintendo's e-Reader, is 3 times finer than that, at a bit over 300 dpi, improving data density by an order of magnitude.
"Why ZFS for home": - http://uadmin.blogspot.com/2006/05/why-zfs-for-hom e.html
"Here are ten reasons why you'll want to reformat all of your systems and use ZFS.": http://www.tech-recipes.com/rx/1446/zfs_ten_reason s_to_reformat_your_...
And some more technical explanations from Sun's Chief Engineer: - http://blogs.sun.com/bonwick/entry/zfs_end_to_end_ data
- http://blogs.sun.com/bonwick/entry/smokin_mirrors
you had me at #!
Any harder than implementations of tar, or even implementations of sh if you want to put GNU tar in .shar format? At least .shar is reasonably human readable and can be unpacked if you don't have a Bourne shell handy. My recommendation: On each volume, include two archives: a .shar archive containing the source code for a PAR reassembler, .tar unpacker, and .gzip decompressor in a widely supported language such as C, and a "part" of your .tar archive.
I also looked into this problem for storing files on large external hard drives. The conclusion that I came to in the end was that at this point in time there really is only one option if you want to be able to access the drive from Windows, Mac OS X and Linux. That option is the Mac HFS Extended file system. Yes, you do have to purchase MacDrive in order to access HFS+ with Windows, but it is a very well-established and popular product that works well and is going to be around for a long time, so it's a safe investment. There is also a driver for Linux 2.4 and 2.6 kernels here. HFS+ has been made more popular because of all the people who want to be able to access their Mac-formatted iPods under Linux.
Your only other choices for cross-platform compatibility are FAT32, NTFS, or Ext2, and they all failed my requirements in various ways.
FAT32 is the most universally readable/writable by most operating systems, but it has serious problems. The main issue is the 4GB file size limit, which was absolutely ridiculous even several years ago. The other problem is that Windows simply won't allow you to format a drive larger than 32GB (or is it 127GB) as FAT32 anyway, but the file size limit is much more of a problem. The only other option that Windows offers you natively for formatting large drives is NTFS. That solves the filesystem and file size limits but then you block stable read-write access from any other OS. There is no read-write NTFS support under Mac OS X, and the read-write NTFS support under Linux is still experimental.
I know a lot of people are recommending Ext2/3, and I also used to think that was the answer, but unfortunately the support for Ext2 on non-Linux platforms is dismal. There is supposedly an Ext2 driver for Mac OS X but it is basically alpha quality and highly unstable based on the user reports I've seen. Thus, Ext2 fails right there, for me. There are a couple of different options for Ext2 in Windows, and they work fairly well for the moment, but it seems to be one of those situations where one guy took some time to whip up some basic support a few years back when he had some free time. That's not the kind of thing that makes me feel good about being able to access my files easily from Windows in the future. There is no guarantee that it will be updated to work with Vista. There is no dedicated crew of people out there making sure that there is continuing stable support for Ext2 in Windows.
I was quite frankly surprised to see just how poor the cross-platform support for Ext2 was. I really was hoping that the open source world would put a little more effort into making Linux filesystems more accessible to other platforms. Instead what I've found is a situation where basically one or two hobbyists have played around with creating some support for like a summer project, and everyone else just sits back and whines that Microsoft or Apple haven't built support in for Ext2 on their own.
So in the end I plunked down my $49 for MacDrive (and $9.99 for a second license) and started formatting all my storage drives as HFS+. An added benefit is that I can copy files to and from my Mac without having tons of those dot files show up, since HFS+ is the native Mac filesystem and supports the Mac resource forks. A final and very nice benefit is that if the drive is hooked up directly to a Mac running OS X it can support journaling, just as Ext3 does under Linux. For me, HFS+ was the only feasible solution for file storage and archiving, and it's working out pretty well. YMMV, of course.
It's not the most perfect situation, but until everyone is able to agree upon a single, standard filesystem for all platforms I don't see any other workable option. I don't see it happening. Mac OS X and Linux may converge on ZFS in a couple of years, but I doubt Windows will ever join the fold and start supporting an open standard filesystem unless somehow the market learns to demand more standardization.
Because user mode tools such as PAR2 already implement them.
I can imagine scenarios where, for example, the RAM buffer in a hard drive is upset and perfectly encodes the wrong bit into a fileLikewise, I can see scenarios where, for example, the RAM buffer in an application's main memory or in the file system's buffer is upset and perfectly encodes the wrong bit into a file.
ZFS checksums everything on the file-system. If you are using RAID-Z with ZFS, it can detect corruption of the underlying data and correct it. For exmample, if you have a RAID-Z+ZFS with 3 drives, you can "dd if=/dev/urandom of=/dev/sdX" and then do a "zpool scan" and it will figure out what was corrupted and fix it. This is one of the standard demos they show with ZFS.
This is great. Previously I had implemented a fax archive for a client and it was getting corrupted periodically because of some ext3 file-system bugs. Luckily, I had put file checksums in place, and we could generate a report on corrupted files daily, so we could pull them back from the backups.
Sean
"I have heard that the most permanent way of preserving data for long, LONG time is to write your data in stone. Granite being one of the best."
But Granite can crack, and crumble causing file fragmentation.
So carving the PAR files is a lot of extra work!
Being able to transparently divide files above 4gig and have them look like a single file to a supported OS would be gravy.
Sure, I could use archives with checksums or RAID, but it'd be nice if there was an option to sacrifice some speed and space on a single form of storage to improve the reliability without going to such cumbersome lengths.
Is the VFAT 32-Bit MS-DOS file system made available in Windows 95. On CD-ROM/DVD-ROM it's essentially the same as the "Joliet" format. It supports file names up to 63 characters, subdirectories, and blanks in file names. Now, I could be wrong but I think journaling is only important where you have transactional-based file systems, where you are doing update writes and want faster performance with the ability to recover in the event of failure of a transaction to finish, i.e. the computer is rebooted before all of the I/O is done to the file but after the journal was written. (You recover the data by replaying the journal.) For the purpose of creating archival backup I don't believe journaling buys you much of anything since typically you write a whole file as a single transaction (several blocks one after the other in a copy operation) and you restore the specific file the same way (as one copy of the whole file).
Whether we like it or not, while NTFS and ext2/ext3 and a bunch of other file systems might provide better reliability, whenever you look at any system, anywhere, one thing they all have in common, on virtually all media: hard drives, floppy drives, usb thumb drives, removable media cards such as Smartmedia, CF, Memory Stick, cell phones, is the Windows VFAT file system. And everyone: Windows 95, 98, NT, 2000, XP, BSD, Linux, OS-9, you name it, every operating system can read MS-DOS VFAT format file systems.
The lessons of history teach us - if they teach us anything - that nobody learns the lessons that history teaches us.
Archival meaning -- read-only. Multiple OS support meaning -- standard.
:)
This cuts the field down. ISO 9660 would be a good bet, but is a bit "overkill". TAR format (which can be viewed as a "primitive" filesystem) would be my choice. Simple, can be read on all your target systems. If a tar client is not (for whatever reason) easily available, the data can still be simply extracted.
Bad point: the "directory" can only be obtained by scanning the entire byte stream. If that is tolerable (and, by indexing the files stored, is mostly just fine), its the one.
If you need fast directory searching as well, consider ISO 9660. Again, clients to read the format are available (although they may be limited to 700MB at a time).
"tar files" (a bit of a misnomer -- should be "tar format byte stream") can be recorded on any device - floppy, disc, tape, CD, DVD, USB stick. It may even provide amusement -- if someone trys to read a recordable CD with a tar image on it, rather than an ISO image
Just another "Cubible(sic) Joe" 2 17 3061
The amount of paper or stone is related to how important "really important" is.
I'd say "really important" is stuff that needs to survive a collapse of technology or even civilization, but not the collapse of literacy. Things like the Rosetta Stone or the modern equivalents, basic instructions for subsistence farming, core religious texts such as the Bible and Koran, dictionaries, some history books, instructions for making a printing press and other basic inventions that could have been built 4,000 years ago if someone had basic instructions. These need to be printed on 500+ year archival materials and stored in multiple copies around the globe.
"Really really" important is the stuff that needs to survive the collapse of literacy or even the human race. Stuff like "Welcome to the Nevada Nuclear Waste Dump." This needs to be on 10,000+ year archival material in a form that is recognizable by all people literate or not.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
I hear that Reiser is good for 20 to life.
gotta be careful.
The basic sleazeware produced in a drunken fury by a bunch of UCBerkeley grad students was still the core of BIND. --PV
...for FAT32. this is noticeable in an age of dvd backups...