Conference decwet::hsm-4-unix

S�rgio --

> Is there anyway to write the data from any partition to a specific 
> platter in the jukeboxe, without copy it first to the /usr1?

No -- the file must first be copied to the efs (extended filesystem -- the
AdvFS and HSM filesystem), and from there it can be shelved to a particular
platter (if there is room on that platter) using the shelve -m option.

What is the goal for putting the file directly on a platter?  And why do
they want to put it on a specific platter?  Perhaps HSM is not the right
tool.  For instance, OSMS/OSDS would let them have separate filesystems
for each platter side, all mounted at the same time.  When a user does
something that uses one of the filesystems, OSMS moves that platter into
a drive.

-- Pat Tressel

S�rgio --

I should explain something about HSM.  The intent of HSM is to have a
filesystem that can get very large -- a lot larger than the amount of
magnetic storage.  But is should still look like, and behave like,
an ordinary filesystem.  In particular, all files should be visible
in the filesystem by doing ordinary Unix commands like ls.  If a file
were copied directly to a platter, there would be no trace of it in
the filesystem, because the visible part of the filesystem is the AdvFS
(magnetic) part.  Also, HSM is supposed to respond quickly.  But writes
to optical are much slower than to magnetic.  So the data goes first to
the faster medium.  Then, in background, without making the user wait,
the file is later copied to optical.

-- Pat

S�rgio --

I should explain something about HSM.  The intent of HSM is to have a
filesystem that can get very large -- a lot larger than the amount of
magnetic storage.  But it should still look like, and behave like,
an ordinary filesystem.  In particular, all files should be visible
in the filesystem by doing ordinary Unix commands like ls.  If a file
were copied directly to a platter, there would be no trace of it in
the filesystem, because the visible part of the filesystem is the AdvFS
(magnetic) part.  Also, HSM is supposed to respond quickly.  But writes
to optical are much slower than to magnetic.  So the data goes first to
the faster medium.  Then, in background, without making the user wait,
the file is later copied to optical.

-- Pat

	Pat,

	First I'd like to thank you for your help, it was very helpful.

>What is the goal for putting the file directly on a platter?  And why do
>they want to put it on a specific platter?


	This system is running in a big Hospital and sometimes they transport
physicaly some plattes with specifics data to another system (medical system,
not Dec).


	The customer is running DecUnix V3.2c and they intend to make an 
upgrade to V4.0a, but as I could see the HSM is no longer supported with V4.0a.

	The only way to upgrade the system is to change from HSM to OSMS/OSDS?


	Regards

	Sergio Horta
	MCS-SP - BRAZIL

Sergio --

> This system is running in a big Hospital and sometimes they transport
> physicaly some platters with specifics data to another system (medical system,
> not Dec).

Aha -- I think I understand:  They would like to get the file from the
filesystem and copy it onto *another* platter, that is not in use by HSM,
so they can take that other platter out of the jukebox, and they want to
know if they can do this without unshelving the file.

This is possible, but a little tricky if the files are large, because HSM
might have had to split them into pieces on different platters, and because
the filenames are not recognizable on optical.

I'll explain how to do it, but I don't recommend doing this -- it's really
a waste of their time.  If they are short of space in the magnetic part of
their filesystem, they should just let HSM make room -- that's what it's for.

(The first part of this process would be used even if they were going to just
copy the file normally, which is the part about loading the output platter.
They're already doing this part, but I'll include it for completeness.)

First they will need to choose a platter that is not in use by HSM already.
The safest way to do this is to put a platter into the jukebox.  They can
do "listm -f" before they put the platter in, then use the importm command
to get the platter inside the jukebox, then do listm -f again to see what
the new platter is called.  They can then use the loadm command to get the
platter into a drive -- this will let them write on whichever side of the
platter they gave as an argument to the loadm command.  (If they want to use
the other side too, they will have to unloadm the first side and loadm the
other.)

Loadm will tell them the name of the device file for the drive it put the
platter in (it will be one of the op devices, e.g. /dev/op5c and /dev/rop5c).
Once the platter side is in a drive, they can copy to the raw device with
dd, or they can make a Unix filesystem on the platter with newfs, and then
use cp to copy files to it.

Then they will need to find out where the file they're interested in is
located.  They should use the shelvels command to find out what platter
side(s) the file is on.  This example is from the man page:

  # shelvels /xxx/aaa

  name       pri    size    chunk  blk    blk    platter     status
  /xxx/aaa
              0     25999     0     0  -  8     8822        OPTICAL
                              1     9  -  12    8821        OPTICAL

This shows a file called aaa in the HSM filesystem /xxx, with two "chunks":
the first (chunk 0) on a platter side called 8822, and the second (chunk 1)
on platter side 8821.

If the file has status BOTH or MAGNETIC, then the file is already in the
magnetic part of the filesystem, and they should not bother with copying
from optical (if it's MAGNETIC, they can't, because the file is *only*
on magnetic).  So they should stop here, and just copy the file from
magnetic onto their output platter.

If the file has status MIXED (which is very rare), then it has some parts
on magnetic and some on optical.  I'd recommend just copying it from magnetic,
which will copy the remaining pieces onto magnetic.  Or they can use the
shelve command to get all of the file written out to optical, then continue.

Next they need to find out what file on each platter contains these chunks
(they don't have the same directories or names on optical).  To do this,
they can use a utility that comes with HSM, called "showm", which is in
/usr/efs/tools, and is normally used only for examining the contents of
platters during troubleshooting.

To use it, they would load the platter with first chunk into a drive and
mount it using mountm (in this case they'd do "mountm 8822") -- mountm
will tell them which mountpoint it used (the name will be something like
/mo0 or /mo1).  For instance:

  # mountm aa04b
  OK
  Platter mounted on /mo1.

(Note that this platter is part of the HSM filesystem.  They should be *very*
careful not to do anything that will change the contents of the platter --
they should not delete anything or write anything to it, or they will damage
their filesystem.)

When the platter is mounted, they would use showm like this:

  /usr/efs/tools/showm -f /xxx/aaa /mo1

where /xxx/aaa is the path of the file they're interested in and /mo1 is
the mountpoint that mountm used.  The output looks like:

# /usr/efs/tools/showm -f /xxx/aaa /mo1

*******************************************************************************

/mo1/aaaaa/144/Inventory:    (File Type: 6  File Version: 2  Offset: 512)
    Slot: 7.1  Offset: 20992
    Refnum: 727087225  Chunk: 0  SBlock: 0  Flags: 0
    Magnetic File is:
        /xxx/aaa

The piece of information they need from the showm output is the "Refnum".
They should also look at the "Chunk" number, to make sure they find all the
pieces of the file in the correct order -- they should start with chunk 0
and go up in numerical order.

When they have the refnum, then they can file the path of the chunk file on
the platter.

  The first directory in the path is the mountpoint of the platter (e.g. /mo1).  

  The next directory is the filesystem id, or fsid.  (This is the string they
  used with mkefs when they created the filesystem.  They can see it in the
  "listm -f" output in the "group" field for this platter.)

  After that is a directory that is the refnum modulo 127.  (That is, divide
  the refnum by 127 and throw away the fraction, then multiply that by 127,
  which will get a number that is the same or smaller than the refnum. 
  Subtract that number from the refnum -- the result is the name of the next
  directory.)  E.g., using the above showm output:

    727087225 / 127 = 5725096  and a fraction

    5725096 * 127 = 717087192

    727087225 - 717087192 = 33

  Finally, the filename of the chunk is the refnum, then a period, then the
  chunk number.  E.g. for the above chunk, it would be 727087225.0 .

Say that the fsid for this filesystem is abcde.  Then the path of the chunk
0 file is:

  /mo1/abcde/33/727087225.0

So now they have the input file, which is the chunk, and the output location,
which is the platter they imported and loaded and optionally made a UFS on
and mounted.  They can now use whatever means they want to copy the chunk.

Then they can repeat the above for each chunk, appending each to the
output.

You can see that it would be a lot faster to just copy the file normally,
and let it be brought onto magnetic...

;-)

(I'll answer the other question in a separate reply.)

-- Pat

Sergio --

> The customer is running DecUnix V3.2c and they intend to make an 
> upgrade to V4.0a, but as I could see the HSM is no longer supported
> with V4.0a.

That's correct.

> The only way to upgrade the system is to change from HSM to OSMS/OSDS?

The option that is closest to what they have now is NetWorker HSM -- it
would give them filesystems with magnetic as the front end, and optical
(or tape, if they want) as the back end, as now.  But uses a completely
different platter format.  At some point, there will be a migration plan,
but I don't have a date.

Are they using NetWorker to do backup?  If so, then NetWorker HSM is
probably the most convenient option.

-- Pat

Sergio --

> This system is running in a big Hospital and sometimes they transport
> physicaly some plattes with specifics data to another system (medical system,
> not Dec).

Paul Saxon (one of the HSM authors) thinks I misunderstood what you want.
He thinks they may just want to copy from some non-HSM filesystem to a
platter that is not part of the HSM filesystem.  That is, they want to use
a drive in the jukebox, just like they would use a separate optical drive
that was not controlled by HSM, and want to get a platter into that drive
and then copy something to it.  If so, then they only need the information
that was in .4 in the section about putting a platter into the jukebox and
loading it into a drive.

So let me ask:

What are they doing now, to get files onto the platter that they take to
the other system?

What filesystem do the files come from originally?

  - Are they files that are in the HSM filesystem, and are being copied to
    a platter that is not part of the HSM filesystem?

  - Or are they originally in some non-HSM filesystem, and are being copied
    first to the HSM filesystem, then from there to another platter that is
    not part of the HSM filesystem?

  - Or something else?

Note that the procedure is the same for both of these cases, as long as
(in the first case, where the source if the HSM filesystem) they can be
persuaded not to try copying straight from and HSM platter without unshelving.

-- Pat

Sergio --

There's a mistake in .4 -- it says to divide the refnum by 127.  That's wrong --
the value isn't fixed (the default is 179, or, if they rebuild the filesystem,
it'll get increased to 1997).  Instead, it's in the .platter file.  So after
mounting the platter, they'd need to look at the .platter file to get that
number.  The .platter file isn't intended to be read by people, but the number
is in ordinary text, so is visible.  It's the number just after the word
".platter".  For instance:

  # cat /mo1/.platter
  /.platter179

Here, the divisor would be 179.

So the procedure is even worse than described in .4.  Please convince them that
this is a big waste of their time -- let the machine do the work.

-- Pat

Sergio --

There's a mistake in .4 -- it says to divide the refnum by 127, but that's
wrong.  (I also posted a reply .7, which had a different mistake, so if you
saw that one, ignore it.)  For directories, the modulus divisor is 17.  For
files, it's 179 (not 127).  (There was a provision made for changing this,
by recording the number in the .platter file, but the numbers were not, in
fact, ever changed.)

In any case, this is just additional time it would take to copy the file
by hand.  It's better to make the machine do the work -- that's what it's
there for.  ;-)

-- Pat

        Pat,

        Sorry, but I was out for a couple of days.

        I talked with the customer again, and this time I could talk with 
manager. Now I understood exactly what they intend to do and believe me it's
easier them I thought.
        
> This system is running in a big Hospital and sometimes they transport
> physically some platters with specifics data to another system (medical 
> system,  not Dec).

        This is wrong, they transport physically some platters among their
jukeboxes (3) that are spread by the complex Hospital, but all of this 
jukeboxes are connected to three different DEC systems with HSM which run
different applications.
        All theses platters storage images about patient examinations and some
times they need transport this data from one system to another. Because the
software that analyze these images need the data at the local system, and
transfer this amount of data by network isn't a good idea, they transport the
platters physically from one jukeboxe to another, then they try to put all the
information about a specific case inside a unique platter.

	Regards to the issue with the upgrade, the customer is analyzing the 
migration to NetWorker HSM.


	After all this discussion one thing is completely right:  I know much
more about jukeboxe and HSM now, then I knew before.

	Thank you for your help.

	S�rgio Horta
	MCS-SP  -  BRAZIL

S�rgio --

> transfer this amount of data by network isn't a good idea

Why?  Have they tried NFS-mounting the filesystem?  That's the easiest thing
to do, and is the way HSM is normally used.  There are customers doing this
with big CAD and graphics files.

> they transport the platters physically from one jukeboxe to another, then
> they try to put all the information about a specific case inside a unique
> platter.

That might work, but it would take a lot of human time.

If they really want to move files this way, this is what I'd recommend:

If the files will fit on one side of a platter, then they can use the loadm
command to get an unused platter into a drive, use newfs to make a
filesystem on it, mount it, and copy the files there.  Then on the other
machine, they would put the platter into the jukebox, and use mountm to
mount it.  The platter side would just be an ordinary UFS filesystem -- it
would not be part of any efs filesystem.  They would only be using HSM to
load the platter side.

They could do the same sort of thing with any removable disk.

If one platter side isn't big enough, or they couldn't get a removable disk
large enough, then they could use HSM as follows:

Reserve one disk or partition on each machine for temporary HSM filesystems. 
The disk should be large enough that all the data they want to use at the
same time can be unshelved into it.  Make an AdvFS domain on each of these
disks.  When they need to move some files, they can create a new fileset in
the domain on the machine where the files are to start with, then make the
fileset into an efs, copy the files they want to it and shelve them.  Then
dismount the efs, take the platter(s) out, move them to the other jukebox.
Make a new fileset on that machine, make it an efs, using the *same
filesystem id* as the original efs, and rebuild the filesystem. A rebuild
with just a few files would only take a minute or so.  They could put the
whole process of making the new efs and rebuilding in a script.  When they
were done with a temporary efs, they could rmfset the fileset.  (Note that
this last step assumes they also keep the files in some other filesystem,
and only use the temporary filesystems for moving files.)

Another possibility would be to forget using HSM and platters, and instead
copy the data to an ordinary magnetic disk (not a removable disk), and
disconnect the disk and carry the it over to the other machine.  This could
be an annoyance, because unless they have StorageWorks enclosures or
something like that, from which they can remove the disk without shutting
down the system, they'd have to shut down both systems to move the magnetic
disk.

I do *not* recommend trying to put the files on a specific platter belonging
to a filesystem that *also contains other work* that they don't want to move
to the other machine, because although they can suggest to HSM that it should
put the files they want on some platter, there's no way they can stop HSM from
putting *other* files on that platter.  So if they take that platter out of
the jukebox, and someone needs a file from that platter, it won't be there.
Also, the -p option to shelve is *only a suggestion* to HSM -- HSM *can* put
the file somewhere else.

Really, NFS is the simplest thing.  Please ask them if they've already tried
it, and, if they have, why they don't like it.  There are some tuning
suggestions for NFS used with HSM that we can give them.

-- Pat

S�rgio --

> After all this discussion one thing is completely right:  I know much
> more about jukeboxe and HSM now, then I knew before.

;-)  Good!

> Regards to the issue with the upgrade, the customer is analyzing the 
> migration to NetWorker HSM.

The product manager for NetWorker HSM is Craig Huber (DECWET::HUBER) --
he can get any technical information you need.

-- Pat