On 3/10/11 4:16 AM, Steven Hirsch wrote: Friends don't let friends store their archives on a media that requires physical contact with a read/write head.

On Thu, 10 Mar 2011, Al Kossow wrote: Yow. That's hard-core! --

Since whehen has a hard drive required physical ocntact between the media and the read/write head? In fact it's when such contact takes place that uyou have problems ;-) -tony

In article <CC28F43ED4708D489ABCF68D06D7F55604243E41FC at 505DENALI.corp.vnw.com>, Rich Alderson <RichA at vulcan.com> writes: Yes, and while hard drive heads shouldn't be touching the medium, bad things happen when they do. And that was Al's point -- heads touching the medium do bad things in the context of archival processes. -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://legalizeadulthood.wordpress.com/the-direct3d-graphics-pipeline/> Legalize Adulthood! <http://legalizeadulthood.wordpress.com>

On Fri, 11 Mar 2011, Al Kossow wrote: Why JBOD over RAID5? g. -- Proud owner of F-15C 80-0007 http://www.f15sim.com - The only one of its kind. http://www.simpits.org/geneb - The Me-109F/X Project ScarletDME - The red hot Data Management Environment A Multi-Value database for the masses, not the classes. http://www.scarletdme.org - Get it _today_! Political correctness is a doctrine, fostered by a delusional, illogical minority, and rabidly promoted by an unscrupulous mainstream media, which holds forth the proposition that it is entirely possible to pick up a turd by the clean end.

On 3/11/11 2:05 PM, Richard wrote: That is one of the problems that I have working with archivists trained in the preservation of paper. We are blessed with working with our artifacts that can be copied without loss, and can be easily indexed, but we have no media of sufficient capacity or readers to recover them for more than a few decades, and there is even less money available for digital archives than traditional paper ones.

On 3/11/11 4:03 PM, William Maddox wrote: I had looked at this a while back. The problem is what it is targeted at solving: "The original idea behind this project was to provide a tool to apply the data-recovery capability concepts of RAID-like systems to the posting and recovery of multi-part archives on Usenet." This doesn't map at all to use in a digital repository, where you (well, "I") don't want to explode a container and scatter it across physical disks. I guess the big philosophical issue I have with these schemes is do you wrap something around a data container (try to make it self-describing), or leave it as two separate containers ("read-only" and "up datable").

On 3/11/11 5:45 PM, Rich Alderson wrote: Leaving the original container as-is, and having the metadata completely separate. This lets you to know that the container should never change so it can be written to a write-once medium, or copied, knowing that the data will never intentionally change. The data that describes the container, though, is known to change over time. Browsability or not.. A long-running argument at CHM for storing assets. Bitsavers, and my working internal archive, are arranged hierarchically. The big difference between the two is while bitsavers is almost exclusively by source or vendor, the internal one is really a collection of archives with differing structures depending on content. Metadata is minimal (as Richard has noted in bitsavers). The 'real' CHM archive started out as a hierarchy, but switched to directories named after the month when the asset was added, since it was becoming increasingly awkward and time consuming coming up with categories, and there was no way to automate the repository ingest process (we had hundreds of pictures taken of objects created while cataloging the collection with no manufacturer directories for them to go into for example). There was a decision that the collections database (Mimsy) was going to be the primary way to locate assets in the archive. This is the logical way to go. Hierarchical databases (which is really what you're creating with directory trees) are known to be less flexible than relational ones. The directory heirarchy is a stopgap to provide some structure for the containers until more detailed metadata can be created. If a catalog record is created at the time the container is added to the archive, and is a efficient way to browse in the database, structuring the containers hierarchically isn't necessary.

I'm not arguing for hundreds of TB of tape, or against using sata drives, here, but: If the wear of validating your media is killing your media, you've got a media refresh problem. You're supposed to be migrating the stuff forward onto newer media every ~five or so years anyway, so that you don't get bit rot, continue to have access to working drives, etc. De

I realised from the start that your oriuginal comment didn't exculde hard drives (does anyone honestly believe i didn't know that a head in a hard disk flies over the disk, it doesn't toucvh it). Richard (I think) then raised the issue of a head crash, and I mistakenly assuemd he was commenting on a dislike of hard drives for archinving becasue they can crash.. My comment was intyerned to point out what everyoen knwos, that your oribialn comment doesn't exclude such drives. -tony

On Fri, Mar 11, 2011 at 3:23 PM, Rich Alderson <RichA at vulcan.com> wrote: Yes and Yes. I have a crashed platter from an RK05F. It would make a "nice" clock face. As an obj d'art, it's a success. -ethan

On Wed, Mar 09, 2011 at 01:49:58PM -0800, Al Kossow wrote: You can still get that by using a format that does file level compression, like afio. This also limits data loss in the case of corrupted bits to just the file directly afflicted, which is why I use that format for my backups. Kind regards, Alex. -- "Opportunity is missed by most people because it is dressed in overalls and looks like work." -- Thomas A. Edison