"John E. Malmberg" wrote: > > On Thu, 25 Apr 2002, Illtud Daniel wrote:
[] > > but I'm fairly sure that the > > mac file sharing services certainly aren't aware of any offline > > attributes. > > There are two ways to handle HSM, swap part of the file or swap all of the > file. OTG DX2000 swaps the whole lot, leaving an (empty) stub file. > This would make Windows files happy. I am not sure about the Mac's, as > they may expect a different file format, or the resource fork may be a > factor. The resource fork is handled by the Mac file sharing application, which may put it a seperate file/directory (like CAP, netatalk, SFM) or in a different file stream (like MacServerIP can optionally do - v useful, in that it keeps everything tidy, big headache in that *nobody* handles NTFS streams properly, not MS, not OTG, not nobody I've found). Keeping them in seperate files/directories mean that you can set your shelving policy not to touch these (tiny) files, which takes away some mac fileserving headaches. > The question that none of the Windows based HSM vendors would give me an > answer on was: Is there any way to make sure that a copy of all files > shelved and unshelved exists on the storage robot, and how do I restore > things when the real disk fails. I would think that question should be > easy to answer. Now I'm confused. It may be because that before coming to this thread my HSM terminology was different to yours. I use 'migrated' for when a file is written to tape (or optical, whatever). 'fetched' for getting it back and writing it to the stub file, 'purged' for removing the file from the extended volume and replacing it with a stub file. You purge only migrated files (for obvious reasons), and a file open on the stub will trigger a fetch. To answer your questions with regard to OTG DX2000: How do you know that a copy of all files shelved exists on the robot? Assuming you mean 'shelved' to be 'migrated & purged' and 'unshelved' to mean 'migrated but not purged', then you don't know, you trust. You can run tape reports to list what's on each tape, but bugs notwithstanding, if a file's been migrated, then it should be on the tapes. DX can backup its internal database (stub file -> tape location) to file which you can stick somewhere safe. In event of distaster, you can rebuild the stubs by just restoring from this file. You can read about this on OTG's website: http://www.otg.com/KnowledgeBase/default.htm try 'dxdrivedump.exe' - that knowledge base will give you a lot of info on how DX does stuff. > > I'll be trying samba (and netatalk) on a HSM'd volume on Monday, so > > I should be able to report back, if there's interest. > > I am sure that there is interest. Because of the caching issue, unless > you have enough files so that they all do not fit on the disk, you may not > notice a performance problem. :) We'll force them to tape, don't worry! The disk is 1.44TB, so yes, we'll have a job filling it, but you can set policies to ensure that migrating starts when your disk reaches 0.01% full, or to migrate as soon as a file appears on the volume, and to force a purge (stubify) of all files. By the way, we're moving to ADICs AMASS because we've had problems with DX2000 which have never been resolved (including loss of hundreds of gigs of content, which isn't fun). An open HSM solution would be a godsend. -- Illtud Daniel [EMAIL PROTECTED] Uwch Ddadansoddwr Systemau Senior Systems Analyst Llyfrgell Genedlaethol Cymru National Library of Wales Yn siarad drosof fy hun, nid LlGC - Speaking personally, not for NLW