Re: [Linux-decnet-user] fal problems

[Patrick C. <pa...@ty...>]

On Wed, Jun 04, 2003 at 10:23:11AM -0700, Larry Baker wrote:
>    I've run into some problems using linux-decnet fal with OpenVMS BACKUP:
>     
>    1. I set up linux-decnet to start fal with the -m option (create/read
>    record attribute metafiles in a .fal subdirectory).  It is not reliable. 
>    I have files that were created by fal, but there is no corresponding
>    metafile entry.  I changed the fal startup to use -ae.

That's an interesting one I havn't seen. Apart from when the .fal directory is
created by one user and a different user tries to write files into it and can't
because the permissions are insufficient. The thing to do is to run fal with -vv
and see if it issues the "creating metafile reecord" message.
     
>    I'd like to see the metafile format documented (on the fal man page?). 
>    Better yet, I'd like fal to use an .fdl metafile directory with ASCII .fdl
>    files that conform to the OpenVMS FDL specification.  (This is the way
>    Process Software's MultiNet NFS client stores OpenVMS file attributes.) 
>    That way, I can change the file attributes with a text editor, if
>    necessary.

The format is documented in the source code (!) as follows:

    // Structure of the metafile
    class metafile_data
    {
    public:
	unsigned short version;
	unsigned short rfm;
	unsigned int   rat;
	unsigned short mrs;
	unsigned short lrl;

	// For variable-length records with no carriage control:
	unsigned int  num_records;
	unsigned short *records; // This is really written after the structure

	static const int METAFILE_VERSION = 2;
    };

FDL is a nice idea but it would take me a long time to write a parser for that
and I just don't have the spare time to do it. If you do, please submit a patch
I'd love to incorporate it.
     
>    2. fal does not negotiate the buffer size like OpenVMS FAL does. 
>    Sometimes remote BACKUP operations work; other times they do not.  I had
>    to use SET RMS_DEFAULT /NETWORK_BLOCK_COUNT=64 on OpenVMS to eliminate the
>    failures ("%BACKUP-E-READERRS, excessive error rate reading ...").

I have had to do this when copying from VMS to VMS. It depends on a lot of
things. Linux is not VMS and doesn't know all the things VMS does. I've
documented this in the FAQ too.
     
>    3. fal appears to limit the file size to 2 GB.  (This may also be true of
>    OpenVMS FAL as well; I don't know.)  The reason I installed linux-decnet
>    was to use my Linux system as an online repository for OpenVMS BACKUP save
>    sets.  I originally tried to use NFS, but the TCP/IP package on our
>    OpenVMS systems only supports NFS version 2 clients/servers, which limits
>    file sizes to 2 GB.  It appears linux-decnet's fal has the same limitation
>    (because of the DAP protocol?).  If this is truly a restriction of the DAP
>    protocol, that's a killer for us -- we won't be able to use linux-decnet.

I'm not sure about that. there's nothing in the DAP spec that implies a 2 gig
file limit AFAICT. looking at the libdap source code I have used longs where
loff_t would probably be more appropriate and I suspect it may not be built
with __LARGEFILE64.
     
For sequential file (eg savesets) you should be able to make fal cope with large
files by rebuilding with -D__USE_LARGEFILE64. operations that do RFA access will
need a small amount of work in the library(and maybe it's callers) to cope with
long offsets. If you do this remember to add it to CXXFLAGS and CFLAGS in
Makefile.common and rebuild everything (and reinstall the libraries).

Also, make sure you are using a Linux filesystem that can cope with large files.
ext2 used not to be able to (reiser can).

My problem here is lack of VMS machines with >2G of free disk space so anyone
elses testing is appreciated.

patrick