The jukebox file server is the core of iXOS-JUKEMAN. It controls the devices, and replies to NFS requests and to requests from the iXOS-JUKEMAN local file system for NT.
To run the server you need the SCSI driver, the cdnfsd server, and the
cdadm administration program. The server and all the programs and files it needs are in the installation directory.
All paths described here are relative to the installation directory.
cdnfsd.exe (NT) or cdnfsd (UNIX) is called by administrator (NT) or
root (UNIX) without parameters. It runs as a daemon and receives requests from NFS clients and from
cdadm.exe (NT) or cdadm (UNIX) and the iXOS-JUKEMAN native file system for NT. It creates
logfile.txt for messages and a small volumes database for CD names and
properties. It needs a server.lic file containing the license key and a server.cfg
file containing basic configuration.
To enable task distribution and efficient service to a large number of clients, the server splits into separate processes for each drive or changer. These processes appear in the process table. The number of processes increases with the number of devices. They share text and data to minimize load on the computer.
The server controls devices for handling CDs and exports the CDs in a single large file system in which each CD is represented by a directory. NFS clients need just a single mount, and PC clients connect a single network drive.
The server hides the physical positions of the CDs. Each CD is represented by a subdirectory, whether it is in a storage slot or in a drive. Clients don't know if a CD is actually stored in a jukebox or is a copy stored in another jukebox. They experience faster access to the CD because the server chooses the jukebox with less load.
Jukeman Administrator is a GUI program that can run on any Windows computer in the network. The network address of the host where iXOS-JUKEMAN is running is stored internally by Jukeman Administrator. You can configure devices and views on the file system and insert and remove CDs from a jukebox using the GUI.
To maintain the configuration, the Jukeman Administrator reads and writes the server configuration file
(server.cfg) and a device description file for each device.
You can also edit these files manually (see "Configuring the Server without the GUI Tool" later in this chapter), but it is easier to use the GUI to configure devices and exported views.
The main dialog has five menus, a list of devices, and the buttons you use to configure the devices. The device status is either 'attached' or 'detached'. 'Attached' indicates that a device is controlled by iXOS-JUKEMAN.
The property 'Startup' in the dialog indicates whether a device should be attached automatically at the startup of iXOS- JUKEMAN or manually ('manual'). If a device status is 'detached' and marked with the mouse, then you can see a button 'Attach'. Otherwise a button 'detach' appears.
Start Service: Starts iXOS-JUKEMAN on the host by triggering the command 'net start cdnfsd'.
Stop Service: Stops iXOS-JUKEMAN by triggering the command 'net stop cdnfsd'.
Select Host: Since the GUI can run anywhere on the network, you must specify the name of the host where iXOS- JUKEMAN is running.
The GUI communicates via TCP/IP (port number 4072) with an administration server, which must be running on the (NT) host where iXOS-JUKEMAN is running. In most cases, this will be the local computer (the default), but since the GUI can run on any computer in the network, you can choose a particular host.
In the text box, enter the host name or IP address (xxx.xxx.xxx.xxx). If you have iXOS-JUKEMAN and the GUI
running on the same computer, enter localhost.
When you run the GUI the first time, no host name is specified. The host name you specify is stored in the
ixos.ini file, which is created in the GUI directory.
License Key: Fill in the dialog box to register or update your license information.
File System Views: See "Configuring the Views" later in this chapter.
Volumes: Displays a list of the CDs that are inserted in all attached devices.
Parameters: Shows list of the parameters you can use with iXOS-Jukeman. Double-click a parameter to find out what it does and to change its settings.
Buffers and caches: Use this command to change the buffer for the incremental file system and the caches for directory structure and regular file data. You must stop service before you can change buffers or caches.
The commands on this menu mirror the buttons below the list of devices. See the following section for information.
Each device controlled by the server needs a description file that describes the device type, the SCSI addresses and properties of the drive, and the SCSI address or the RS232 address of the changer. It also describes which storage slots the server should use; the default is all.
When you use the GUI to configure devices, you are asked for a device name. The GUI then creates a description file using that
name and the extension .dev. So that the server doesn't have to inspect the disks upon each startup, the
information about which CDs reside in which slots of the jukebox is stored in a save file. The name of the save file has the same name
as the description file, but with the extension .sav. So if you have a device named juke1, a
description file named juke1.dev is created in the jukeman directory on the host. After
you attach juke1 the first time, the server inspects the slots and creates a juke1.sav save file.
The name of the jukebox and information as to whether it should be attached automatically is stored in the
device section of server.cfg.
Note: If you do not use the GUI to configure the devices, you can give the description and save files any name you want. Put
them into the directory where cdnfsd.exe resides, since this is where iXOS-JUKEMAN looks for them.
However, random names can cause problems if you use the GUI afterward, since the GUI only accepts description files with the
name of the device (stored in server.cfg) and the extension .dev.
You can add a device by clicking the New button under the device list in the main dialog.
In the Device Setup dialog, click Device Browser, and then select the appropriate search criteria. Select the device you want to add and click Configure. The fields in the dialog are filled in for you. Click OK.
To modify or remove a device, select it in the device list and click Setup or Remove.(Before you remove a device, stop the service.)
Add descriptions of other devices in the order of the jukebox (see the Note in the "Defining Devices" section of Chapter 2). Use the radio buttons in the upper left part of the dialog to choose the properties of the drive you want to use. "Not available" or "defect" has the same effect as declaring the drive "defective/missing." Choose "Not used by file system" for a recorder drive that you want to use only for this purpose (see "Producing CDs in Jukeboxes" in Chapter 5). For a recorder drive that you want to use for transparent writing through the file system (see "Writable File System" later in this chapter), choose "Used for track recording also." In all other cases, stick to the default choice used by the file system.
You can change these drive settings later by clicking the Setup button, choosing the drive, and clickingDefine.
If your device type is a hard disk image, you need to specify a file with an .iso file name extension instead of
drives. Note that the file system of your local computer will be listed. If you run the GUI and iXOS-JUKEMAN on different
computers, first map the hard disk that you want to access.
Robot: Most device types need a robot specified. If this is a SCSI target (most devices) or a LUN of a SCSI target (Pioneer 18 CD or Sony), all choices are listed in this combo box. If it is a serial port (Kubik or NSM jukeboxes), COM1-COM4 are listed.
If your jukebox type does not need a robot specified (for example, a Pioneer 6-CD changer), this combo box is disabled.
Robot ID: Most jukeboxes do not need a robot ID specified. If this is the case for your jukebox type, the Robot ID box is disabled.
For NSM jukeboxes, a serial line controls up to 16 jukeboxes, so you should provide an ID from 0 to 15. See your jukebox manual for details about this ID.
Attach at Server Start:Leave this box checked if you want your device to be attached automatically when the server starts. If you uncheck it, you have to attach the device explicitly.
Double sided: Check this box if you are configuring a WORM or MO jukebox (otherwise this box is disabled) and your WORM and MO discs are double sided.
Use only these slots:To save time, you may want to use only a few slots during installation or to store recordable CDs in
unused slots. Specify the slots you want to use by a line such as 1-3 or 1,2,4-6. If you
do not want the server to use any slots, type-. In this case you have to make CDs known to the server by explicitly testing them.
Administering the server means starting and stopping it, attaching and detaching devices, testing slots, and changing and renaming
CDs. To do this, the server must be running. You can use the Jukeman Administrator GUI or type the cdadm
commands into a command line as described elsewhere in this manual.
Note: Communication between the GUI and server is always initiated by the GUI. That means, for example, if a device is
detached by a cdadm command in the command line or is switched off, the server cannot inform the GUI.
Therefore it will still appear as attached in the device listbox. If you want to be sure about the current server state, restart the GUI
or click the Attach/Detach button. This also applies to situations where the GUI issues a timeout error.
To attach or detach a device, select it in the device list in the main dialog and clickAttach/Detach. To do this, the server must be running. If you stop the server, all devices will be detached.
Note: When you attach a device the first time, the server inspects all slots. The GUI waits for the server to confirm that the device is attached and you cannot take any other action using the GUI. To avoid this, click the Cancel button. This does not stop the attach process, but you no longer have to wait for a response.(to stop the attach process, clickDetach). If you clickCancel, the GUI does not recognize that the device is attached and it continues to appear as detached in the device listbox. To check whether the device is already attached, click Attach again.
The Contents dialog lists all slots with their current contents.
Name Format: The name of the CD is displayed as it is burned in the CD (Original) as the default. You can also choose
PC, RR, or HS format. The names of the CDs are stored in the volumes database.
Insert/Remove: If your jukebox has a mail slot, such as Mercury, Kubik, or standard jukeboxes, use the Insert/Remove button to change, import, or export a CD using the mail slot.
Insert instructs the server to search for a free slot and then open the tray or release the mail slot. Insert a CD and press the button or close the mail slot. If you selected one or more slots in the slot list, the choice of slots is restricted to these slots.
Use Remove to export a CD from the jukebox. If you select one slot, the server removes this CD. If you select a set of slots or no slots, the server inspects the set or all slots and searches for an invalid CD. If no invalid CD is found, it searches for any CD and exports it to the mail slot.
Change CD: This button is displayed if your jukebox doesn't have a mail slot to exchange CDs. To change a CD, select the slots you want to change and click Change CD.Then change the CDs by whatever means the jukebox provides. After the change, the server tests the selected slots and updates the display just as if you had clicked Test.
Test: If you are not sure about the slot contents, for example, if you changed CDs without telling the GUI, you can update the display by selecting one or more slots and clickingTest.
Rename:For PC, RR, and HS formats you can change the name of a CD. Select the appropriate format, select one CD, and click Rename.The name is changed for the currently selected format.
Move CD:If a client wants to access a CD, the file system automatically moves it into a drive. However, you may want to move a CD explicitly into a certain drive, for instance into a recorder drive to burn a CD. To do so, click the Move button and select a slot number and a drive.
You can also free a drive by moving a CD back to its slot. Simply select this option and the drive.
Rescan: Click this button to search every slot for new volumes (this could take a long time).
IncrementalFS: Displays information about a CD that is being written incrementally. See Chapter 5, "The Writer," for information about the incremental file system/
server.cfg contains—among other entries—descriptions of the exported views. A view represents a
set of CDs that can be mounted by clients.
For PC clients, a view is a drive letter on the host that can be shared. For UNIX clients, a view is a path that can be mounted with NFS. This path consists of a directory and the name of the view.
If you configure server.cfg with the GUI, the directory will always be \views. Thus the
path of a view with the name pc would be \views-pc. The GUI can only read and
process views with the directory name \views. So if you prefer to edit
server.cfg manually, but plan to use the GUI afterward, you should only use this directory.
To configure views, select the File System Views command from the Configuration menu in the main dialog.
You can add a view by clicking the New button above the view list.
A new view is added to the list. Type up to eight characters to name the view.
For UNIX clients, a view is a path on the host that can be mounted. This path will have the name
/views/viewname, where viewname is the name you fill in. The path is
created as soon as you restart the server.
Visible Volumes/Excluded Volumes: Use these fields to specify which volumes will be visible to clients mounting the view. If you type *, all CDs are visible. You can restrict the set of CDs by explicitly listing those CDs that should be visible. This is useful to restrict and simplify access to CDs.
The characters ? * [- ^] {,} in CD names are used as csh-styled wildcards: ? for
any character, * for any string, […] for alternative characters, - for a range, ^ for forbidden characters,
and {…,…,…} for alternative strings. The CD names are separated by a space key. Example: sdk*
develop win* nt*.
Format:In a file system view, a client sees a set of CDs in one of the three name formats supported by the server: PC, Rock Ridge, or High Sierra.
If a client mounts a view for which the High Sierra format is specified, it sees the file and directory names exactly as they are stored on the CD in High Sierra or ISO 9660 format. The version numbers that are part of the ISO 9660 standard are useless for most clients. This format is supported mainly for completeness. The PC format is a modified High Sierra format, optimized for PC clients. The version number is cut off and all characters are converted to lowercase.
If a client mounts a view for which the Rock Ridge format is specified, it sees the file and directory names in High Sierra or ISO 9660 format, modified by Rock Ridge extensions if they are available. These ISO 9660 compliant extensions are a common way to add UNIX names to the ISO 9660 format. Rock Ridge extensions may also contain owner and permission.
Available as Drive: For PC clients, a view is a file system that is represented as a drive letter on the host and can be shared. Choose the drive letter from a list of letters that are not yet in use. The new drive is created as soon as you restart the server.
To modify a view, highlight its name in the list and change the option settings.
To remove a view, select it in the view list and click Remove.
The view will be configured by modifying server.cfg. iXOS-JUKEMAN reads server.cfg only once at startup. Therefore,
if iXOS-JUKEMAN is already running, you are asked if you want to stop and restart iXOS-JUKEMAN, so the changes can take effect.
You configure the server using server.cfg and device description files. The iXOS-JUKEMAN software
contains examples of these files that you can change to meet your needs.
server.cfg contains descriptions of exported views, devices to be attached at startup, and server
parameters. The description of exported views is mandatory. The list of devices is useful, but you can also attach devices using an
administration command. You can often use the parameters' default values.
server.cfg is divided into named sections, which are limited by braces:{}. Each section can contain named
subsections. For example, the description of views is a section named views; it contains a subsection named
list that lists the names of all views and one subsection for each view. These subsections, named by the view
names, contain several subsections describing the properties of the view: the name format to be used, the CDs allowed to be visible,
and the CDs that are denied.
The following code is a sample of server.cfg.
views {list { /views/pc /views/rr }
/views/pc { format {pc } disks { * } drive { X } }
/views/rr { format {rr } disks { * } drive { Y } }
}
devices {
list { nsm31 }
nsm31 { startup { automatic } }
}
parameters {
loglev=5
}
Note:The 'drive' portions of this example apply to NT users only.
This sample configuration describes two exported views, named /views/pc and
/views/rr. Each view exports all disks, but they differ in the file names presented to the clients:
rr means ISO 9600 + Rock Ridge Extensions where applicable
hs means pure ISO 9660 or High Sierra Format (rarely used)
pc means modified ISO 9660 for PC-clients.
csh-like wildcards are also accepted.
For example, an additional mount point,
/views/ms { format { pc }
disks { vc2* ms* win* *nt* } drive { Z} }
might be useful for users who just need PC development tools and do not want to see any other disks.
Note:The 'drive' portions of this example apply to NT users only.
The default file included with the examples works for most configurations. However, if you have special requirements, you'll want to edit the configuration file to customize the server. The next sections describe how to configure file system views, attach devices automatically upon startup, and change internal server parameters from their default values.
For UNIX clients, a file system view is a path that can be mounted by clients. The NT version presents the same file system view as a
drive letter that can be shared by PCs. In each file system view, a client sees a set of CDs in one of the three name formats supported
by the server: hs, rr, and pc. The standard configuration offers two
views, one containing all CDs in pc format, the other containing all CDs in rr format.
If a client mounts a view with the hs name format specified, it sees the file and directory names exactly as they
are stored on the CD in High Sierra or ISO 9660 format. The version numbers that are part of the ISO 9660 standard are useless
for most clients. This format is supported mainly for completeness.
If a client mounts a view with the pc name format specified, it sees the file and directory names in a modified
High Sierra or ISO 9660 format, optimized for PC clients. The version number is cut off and all characters are converted to
lowercase. This is important for PC clients that insist on converting lowercase to uppercase. If these clients receive uppercase names,
they convert them into strange artificial names.
If a client mounts a view with the rr name format specified, it sees the file and directory names in High Sierra
or ISO 9660 format, modified by Rock Ridge extensions if they are available. These ISO 9660 compliant extensions are a common
way to add UNIX names to the ISO 9660 format. rr extensions may also contain owner and
permission.
A UNIX client mounts a view with the pc format in mount point /rom_pc. The
command 1s -a1 /rom_pc yields: total 23
| total23 | |||
| dr-xr-xr-x | 19 root | root | 304 Apr 17 13:21 |
| drwxr-xr-x | 34 root | root | 1024 Apr 15 13:53 |
| dr-xr-xr-x | 2 root | root | 2048 Mar 18 15:51 aiim |
| dr-xr-xr-x | 2 root | root | 4096 Mar 1 1995 cebit_95 |
| dr-xr-xr-x | 2 root | root | 2048 Jan 1 1996 cebit_96 |
| dr-xr-xr-x | 2 root | root | 2048 Jan 10 19:21 compuser.ve |
| dr-xr-xr-x | 2 root | root | 2048 Jan1 1995 hp_sap_c.d |
| dr-xr-xr-x | 2 root | root | 4096 Jul 17 1995 klg007 |
| dr-xr-xr-x | 2 root | root | 4096 Mar 1 16:24 logimedi.a |
| dr-xr-xr-x | 2 root | root | 2048 Dec 6 1994 sap_r3 |
The same UNIX client mounts a second view with the Rock Ridge format in mount point /rom. The output of
1s -a1 /rom is:
| total23 | |||
| dr-xr-xr-x | 19 root | root | 304 Apr 17 13:21 |
| drwxr-xr-x | 34 root | root | 1024 Apr 15 13:53 |
| dr-xr-xr-x | 2 root | root | 2048 Mar 18 15:51 AIIMSHOW96 |
| dr-xr-xr-x | 2 root | root | 4096 Mar 1 1995 CEBIT-95 |
| dr-xr-xr-x | 2 root | root | 2048 Jan 1 1996 CEBIT_96 |
| dr-xr-xr-x | 2 root | root | 2048 Jan 10 19:21 COMPUSERVE_INSTALLATION |
| dr-xr-xr-x | 2 root | root | 2048 Jan1 1995 HP_SAP_C.D |
| dr-xr-xr-x | 2 root | root | 4096 Jul 17 1995 KLG007 |
| dr-xr-xr-x | 2 root | root | 4096 Mar 1 16:24 LOGIMEDI.A |
| dr-xr-xr-x | 2 root | root | 2048 Dec 6 1994 SAP_R3 |
For each view described in server.cfg you must specify a CD set, a list of CDs that will be visible to clients
mounting the view. Most CD sets contain the name *, which means all CDs are visible, but you can restrict the set of CDs by explicitly
listing only those CDs that should be visible. This is useful to restrict and simplify access to CDs. For example, a PC software
developer may only want to see disks containing products for PCs, so it will simplify access if you specify a view containing all CDs
with information related to PC development.
The characters ?*[-^] {,} in CD names are used as csh-like wildcards: ? for any
character, * for any string, […] for alternative characters, - for a range, ^ for forbidden characters, and
{…,…,…} for alternative strings.
server.cfg
If you want to export all disks to UNIX clients in rr format, most disks to PC clients in
pc format, and some disks to PC developers in pc format, you must specify three views, each
containing a path, a format, and a disk set. One directory shall make accessible all CDs with first letter a,b,c,...,m and with name
not beginning with archive. A second directory shall make accessible all CDs beginning with letters n,...,z. The following
example shows you, how to configure this
dive { z } views {
list { /views_rr views_pc find_easier }
roots {
/views_rr {format {rr} disks {*} drive {Y} }
/views_pc {format {pc} disks {*} drive {X} }
find_easier { views { list { a_m n_z }
roots {
a_m {format {pc} discs { [a-m]* } deny { archive* } }
n_z {format {pc} discs { [n-z]* } }
}}}}}
Note:The 'drive' portions of this example apply to NT users only.
The above configuration would present the following filesystem:
server.cfg contains a view section for the CD views. This section
defines three file system views. /views_rr exports all CDs in rr format. The other views
use pc format. Clients that use /views_pc see all disks. Clients that use
/find-easier see two subdirecories with name a_m and n-z. Note that in NT the first two views are bound to
the drive letters x: and y:.
In drive letter Z: are three subdirectories visible: views_ps, views_rr and find_easier.
The directory find_easier contains two subdirectories a_m and n_z. For example, a CD with PC-format-name 'austria' is visible in directory 'a_m'. But directory a_m does not contain a CD with name 'archive-11-96', for example.
If the drive letter z: is shared over the pc network, then PC client computers can map the filesystem under z: as a network drive.
A UNIX client computer can also mount the filesystem view. A example NFS mount command is:
# mount -o retrans=14,soft,timeo=99 hostname:/ /mount_dir
Then in directory /mount_dir the same directory structure is visible as in drive z: on the server computer.
See Chapter 2 for a description of how UNIX exports file system views.
You can use the cdadm command (see "Controlling the Server" later in this chapter) to dynamically attach
or detach devices while the server is running. You can also define a list of devices to be attached automatically upon each server
startup. This is useful for crash recovery.
For example, if your server computer crashes and reboots, the jukebox file system server restarts. If the server is set up to attach
devices automatically, it will not accept file system requests until all devices are attached. If you attach devices using
cdadm after server startup, there is a small time gap in which the server accepts requests without access to the
CDs. During this time, it will send error replies to most CD requests. You can avoid this if the devices are listed in
server.cfg.
For NFS especially, the result of automatic attach is that a server crash does not affect clients. They do not receive errors, they just wait for the server to reply. This demonstrates the power of the stateless NFS concept.
The devices section contains a subsection named list that lists the complete name of the
corresponding device file. It includes a subsection for each listed device that defines if it should be attached automatically upon
server startup or attached manually.
A device for which manual attach is defined has no effect in server.cfg (apart from making it known to
the GUI in NT, so you can manually attach it through the GUI). This allows you to disable automatic attach of a device without
deleting it in server.cfg.
A device for which automatic attach is defined is attached by the server upon startup before the server accepts any file system requests. This avoids a time gap in which the file system is present but incomplete.
Suppose you have two jukeboxes, whose device files are named mercury.dev and
pioneer.dev, and you want the Mercury to be attached automatically upon server startup. The
devices subsection in server.cfg should look like:
devices {
list { mercury pioneer.dev}
mercury {startup {automatic} }
pioneer.dev (startup {manual } }
}
The only effect of including pioneer.dev in the file is to declare it for the GUI in NT; it has no effect in UNIX.
You can change server behavior using parameters, though the default values usually work. server.cfg
entries override default values and command options override default values and server.cfg entries.
You can change a few server parameters dynamically while the server runs. See "Controlling the Server" later in this chapter for details.
All server parameters have the format key=value or key { value }
where key is the parameter's name and value is a non-negative integer in decimal
or hexadecimal notation. For example, suppose you want to change the server's log level, which is controlled by the parameter
loglev. The default value for this parameter is 4, and you want to use the value 5.
To change a value permanently, add an entry in server.cfg. If there is no
parameters section, create one and list all parameters to be changed:
parameters {
loglev=5
}
or
parameters {
loglev { 5 }
}
If you want to change the log level for a single server invocation only, type:
cdnfsd loglev=5
and the server will start with log level set to 5.
If you want to change the log level while the server is running, type:
cdadm setpar loglev 5
and the log level will change dynamically. This method, however, works only for few parameters (see below).
The following descriptions list the parameters with their default values and their meanings.
autodc=1
| That parameter controls the caching of CD directory structures. If a CD is inserted in a drive, then iXOS-JUKEMAN checks if the root directory of the CD is in the cache. If it is not in the cache, then autodc controls the further behavior. No caching is done with value 0. Value 1 means, that caching is only done, if a harddisk cache exists (RAM cache is the default, if no harddisk cache is configured). Value 2 means, that the whole directory structure is cached, even if a RAM cache is used. |
blanks=0
| After changing a CD or issuing a 'test' CD command iXOS-JUKEMAN tries to determine the type of CD. With many reader drives the CD test can not be completed successfully. The iXOS-JUKEMAN moves the CD to a writer drive to get more information about the CD. For example Jukeman will differentiate between a blank CD-R, a non ISO9660 CD or a non finalized CD. The parameter blanks can be used to speed up the test procedure. Value 0 means that first CDs are tested in reader drives (are faster) and eventually in writer drives a second time. Value 1 means, that only writer drives are used. If a CD is inserted and no testing should be done, then value 2 can be set. |
fullvn=0
| If the parameter fullvn is set to 0, then the original CD names are transformed to 8+3 in a PC format view. With fullvn=1 the names in PC format are 32 characters long and in lower case. |
iotimo=60
| Time in seconds until failed CD reads are abandoned. |
loglev=4
| Defines how many messages are printed to the log file. For your first try, use a value of 5 or 6 to see if everything works well. This parameter is most often changed dynamically. |
ignore=0
| All other values cause the server to ignore all file system requests. This can be changed dynamically; for example, to block the server for awhile. |
lwords=5
| The iXOS-JUKEMAN server internally stores last recent log messages in a buffer. If problems occur, then this buffer is written to the logfile. The parameter lwords sets the loglevel for the 'last words'. |
mdelay=3
| iXOS-JUKEMAN has a sophisticated adaptive scheduling policy for accessing CDs. IXOS-JUKEMAN learns from accesses in the past.
When the iXOS-JUKEMAN server has to move a CD out of a drive to insert a new one the server must first select which CD will be removed from the drive to make room for the new CD.. It is often preferable to delay this CD exchange as data requests are usually qued for the current CD. The parameter mdelay sets a limit according the delay. Value 0 means a strong serial use of the access queue (not much sense). The greater the value the longer is a delay even there is no access on the CD. |
report=0
| All other values cause the server to report all non-zero SCSI sense codes. This can be changed dynamically and is mainly useful for debugging. |
trayto=60
| That parameter can be used together with PioneerDRM1004X and SonyCDL-2*** jukeboxes. It is the time in seconds that the
iXOS-JUKEMAN server waits until the mailslot of a jukebox is closed manually. After that time, the mailslot tray is closed
automatically. If a PioneerDRM5004X jukebox is used, then trayto defines the time until the jukebox continues its normal operation. |
jobnum=256
| Defines how many file system requests the server can queue internally. If you have more than 1000 clients, increase this number. |
maxtty=4
| Defines how many serial lines can be controlled simultaneously. |
mountp=10000234
| Defines the program number the server uses to register its mount service if there is no such program already registered. Use 0 for no registration at all. |
memory=0x400000
| Defines the total size of shared memory used by the server. The server maintains all internal tables, for example, job table and device table, and the volatile caches for data. Most table sizes can be changed by parameters, except the volatile data cache, which receives all remaining space after all other tables are created in the shared memory. |
dacnum=0x100
| Defines the maximum number of entries in the volatile data cache |
rtrack=0x20000
| Defines the size of chunks of files to be cached in the volatile data cache. |
jcdnfsp=100003
| This paramter defines with which program number iXOS-JUKEMAN registers its NFS service, if no other program of that kind exists. Value 0 means no registration. |
dcheck=300
| Defines a time intervall in centiseconds. After which time iXOS-JUKEMAN checks automatically whether a CD has been changed in a single CD drive or a CD drive tower. Value 0 inactivates such a check. |
jobnum=256
| Defines how many file system requests the server can queue internally. If you have more than 1000 clients, increase this number. |
maxcvt=1000
| This parameter defines, how many nodes the views tree of the controlled CDs can have. |
portno=4027
| Defines the UDP port for NFS and cdadm requests. |
mountp=10000234
| Defines the program number the server uses to register its mount service if there is no such program already registered. Use 0 for no registration at all. |
Nonfsd=0
| If this parameter is set to 1, then the NFS daemon integrated in iXOS-JUKEMAN does not start. It makes only sense on NT platforms, because on UNIX NFS is the only interface to the iXOS-JUKEMAN filesystem. |
Synclm=0
| With value 1 log messages are written without buffering into the logfile.txt. |
waitpm=0
| If no port mapper is found at startup of iXOS-JUKEMAN, then iXOS-JUKEMAN does also this job. The parameter waitpm sets the time in seconds, how long iXOS-JUKEMAN should wait for a eventually slowly starting other port mapper. |
Rtrack=131072
| Defines the size of chunks of files to be cached in the volatile data cache. Value has to be a multiple of 8192 (8kB). |
The server interacts with drives and jukeboxes, file systems, and admin RPCs. Drives and jukeboxes are controlled by the server,
and file system requests are generated by NFS clients or by the kernel part of the NT file system. Admin remote procedure calls
are generated by cdadm. The RPCs instruct the server, for example, to attach a device.
You can use cdadm either locally or on a remote host. For the latter, the first two arguments to
cdadm should be -h hostname, where hostname is
either the name or the IP address of the remote host.
cdadm is called with variable parameters. The first parameter (after the -h hostname part,
if any) defines the type of the requested action. The other parameters depend on the desired action. The server replies with at
least an error code. If the error code is not 0, the string describes the error, and no more output follows. If the error code is 0, there
might be more output depending on the arguments.
Note: For clarity, a possible -h hostname after the cdadm keyword is omitted in the following survey
list.cdadm null
| Test if the server is alive. |
cdadm survey options
| Print a survey of devices or CDs. |
cdadm attach device
| Attach the jukebox described in device. |
cdadm detach device
| Detach the jukebox described in device. |
cdadm getpar var
| Get the current value of the variable var.
|
cdadm setpar var new
| Set var to new, report previous value.
|
cdadm rename nf old new
| Rename a disk in the nf name format.
|
cdadm import device[list]
| Import a new CD into the device. |
cdadm insert device[list]
| Same functionality as cdadm import.
|
cdadm export device[list]
| Export a CD out of the device. |
cdadm remove device [list]
| Same functionality as cdadm export.
|
cdadm testcd device[list]
| Test slots with changed CDs. |
cdadm movecd device args
| Move an unused CD to an unused drive. |
cdadm writer
| Commands for transparent write features. |
cdadm rescan device
| Re-initialize the internal memory of a jukebox. |
net start cdnfsd (NT ONLY)
| Start the iXOS-JUKEMAN server. |
cdstart.bat (NT ONLY)
| Start the iXOS-JUKEMAN server. |
net stop cdnfsd (NT ONLY)
| Stop the iXOS-JUKEMAN server. |
cdstop.bat
| Stop the iXOS-JUKEMAN server. |
cdadm byebye
| Terminate the file system server. |
null
cdadm null
does nothing. This is useful if you want to test if the server is alive.
survey
cdadm survey options
prints a survey of devices or CDs, depending on several parameters in which you specify list type, columns, restrictions, and sort options.
The order of the parameters is:
Four list type parameters are available, one for devices and three for volumes:
-d
| Print a list of devices (jukeboxes or drives). |
-v
| Print a list of volumes (CDs). |
-n
| Print a list of volumes (CDs) without listing identical volumes several times |
-s
| Print the content of all slots. |
The list type determines the source of information. You can choose the pieces of information you want to see using "+" options. Note
that for a device list only +d can be used.
General parameters:
+d
| Print device names. |
+s
| Print slot numbers. |
+i
| Print i-node number (number in volume database). |
Media:
+m
| type of media. |
+R
| displays 'r', if a CD recorder is necessary to read, 'a' else. |
+a
| displays '@', if the medium is in a drive, '-' else. |
+u
| displays '+', if the medium can be accessed via the filesystem, '-' else. |
+U
| time of the last access on the medium in seconds since 1970. |
+S
| Size of the whole volume including free space. |
Names:
+o
| Print volume names as originally found on the CDs. |
+r
| Print volume names in rr format.
|
+p
| Print volume names in pc format.
|
+h
| Print volume names in hs format.
|
Recordable filesystem:
+B
| Amount of buffered data for a volume. |
+W
| Amount of data written to the disc. |
+w
| W+B (total amount of data for a volume).
|
+F
| S-W (free space on the physical volume).
|
+f
| S-w (available space for more data).
|
+T
| Number of tracks written to the disc. |
Statistics:
+D
| Amount of data (Mbytes) read from one CD. |
-D
| like +D, but sets all values to zero. |
+P
| Number of operations on one CD, i.e. read accesses with max. block size of 64kB. |
-P
| like +P, but sets all values to zero. |
+M
| Number of movements of a CD into a drive. |
-M
| like +M, but sets all values to zero. |
For example, cdadm survey -d +d prints the names of attached devices. cdadm survey -v
+dsipr prints a list containing device name, slot, i-node, and the name in pc and
rr format for all volumes in all attached jukeboxes.
You can restrict the output using parameters such as d=device, which prints only the specified
device or only volumes residing in it. For a volume list, you can apply restrictions for all columns, even if a column is not selected.
For example, cdadm survey -v +sip d=juke.dev prints all volumes in
juke.dev only. cdadm survey -v +dsipr p=ixos96 prints all volumes named ixos96.
Finally, you can specify how the output should be sorted:
s:options
sorts the output list according to the specified options.
options is a list of column names. The output is sorted by these columns. For example, cdadm
survey -v +dsipr s:ds lists volumes, sorted by device name and within a device, by slot number. Like restrictions,
you can use sort options even if the specified column is not printed. Thus cdadm survey -v +dspr s:i
prints all volumes sorted by i-nodes, but does not print any i-node numbers. This may be useful if you want to see CDs in the order in
which they were made known to the server, because the server associates i-node numbers with CDs sequentially.
The results of the commands to show amounts of buffered or written data, free space, and so on, are expressed in kilobytes (1024 bytes).
attach and detach
To make the CDs in a device visible, the device must be attached, or made known to the server. At startup some devices may be
attached automatically (see "Devices to be Attached Automatically" earlier in this chapter). While the server is running,
you can attach or detach devices using the cdadm attach or cdadm detach commands.
cdadm attach device
attaches the drive or jukebox described in device to the server. Unless a save file (see
"Device Descriptions" in Chapter 2) is defined, the server inspects all slots described in the device file. All valid CDs found in these
slots become visible through file system views.
cdadm detach device
detaches the same device from the server. The server moves the jukebox into a basic state, and the CDs in the jukebox are no longer visible.
getpar and setpar
cdadm getpar var
gets and displays the current value of the server variable var.
cdadm setpar var new
changes the server variable var to new and reports the old value. Very few
variables can be changed while the server is running, and not all values are allowed. For most users, only the variable
loglev is useful. For details see "Overview of Server Parameters" earlier in this chapter.
rename
cdadm rename nf old new
renames the CD old into new in the nf name format, which can be -pc, -rr, or
-hs (see "Name Format" earlier in this chapter). old must be an existing name in the name format nf, and new
must not exist. A name exists if it is known in the volumes database, even if there is no CD of this name physically available. Thus if you detach and attach a
jukebox, the names of the CDs in the jukebox can't be reassigned. The new name changed by rename is stored in the volumes database.
import (insert), export (remove), and testcd
The import and export options to the cdadm command are used to put
CDs into a jukebox or to remove them from a jukebox. For convenience, the insert option is equivalent
to import and the remove option is equivalent to export.
The testcd option is used to inspect the contents of the slots when you want to make a new CD known to
the server. (The new CD need not be included in the list of relevant slots. See "Device Descriptions" in Chapter 2). For instance,
cdadm testcd jb.dev 27 causes iXOS-JUKEMAN to inspect slot 27.
Due to the different types of jukeboxes, there are three main scenarios for inserting and removing CDs:
cdadm export device
cdadm import device
cdadm export device name
cdadm import device 20-30
cdadm export device 27
cdadm testcd device
cdadm import device (blocks user requests - now change disks 2 and 3)
cdadm testcd device 2-3 (server inspects CDs and continues normally)
movecd
cdadm movecd device drive slot
moves a CD from slot to drive, where the latter is an integer in the
range of 1 to the number of drives in the respective jukebox (for instance, 4 for a Mercury). Neither the slot nor the drive should be
used by the file system. If the slot is 0 or missing, the jukebox server frees the drive. Note that the drive must be active (not
disabled by a drive=! line in the device file) to be accessible for move commands ( see Chapter 2 for a
description of the different drive=syntax styles).
writerThe commands for the transparent file system are described in the "Writable File System" section later in this Chapter.
cdadm rescan jb.dev
causes some jukeboxes to re-initialize their internal memory. This is useful if you inserted CDs manually and directly into the slots of a Pioneeer 5004X or Grundig M200 jukebox.
terminates the server. Use cdnfsd to restart it.
iXOS-JUKEMAN includes a permanent directory cache on the hard disk.
With this feature the directory structure and filename information of all CDs can be held permanently on the harddisk. This can lead to higher performance, because a file search does not cause a insertion of a CD into a CD drive of a jukebox. If no directory cache on harddisk is defined, then a space of 1MB in memory is used for cache as default. If a jukebox is attached to the server then a hard disk cache should be configured.
Because of sophisticated hash techniques the directory cache has a extraordinarily high performance.
To enable this feature, you have to add lines to server.cfg, either by editing and starting or
restarting the server, or using the NT GUI as described in "Configuring the Writable File System and Directory Cache using
the Administration Tool" later in this chapter.
The following lines are required.
dircache {
file {dircache}
size {25}
}
declares that iXOS-JUKEMAN should create a dircache of 25 MB in the hard disk file
named dircache in the installation directory. Note that you have to stop and start the server to initialize the
directory cache. Also, such lines are inserted in file server.cfg automatically, if the GUI (NT) is used.
The cache is filled on the fly, while clients use the server and encounter non-cached directories and files. Internally the caching occurs under the following conditions:
When setting the size of the directory cache, remember:
iXOS-JUKEMAN includes a feature for caching of regular data. This means, all read data is written into the cache. If cached data is read again, then no CD access is necessary. The cache is built up as a ring buffer. If the cache is filled up to the defined limit, then old data is overwritten.
The default is, that the data cache resides in the RAM and has a size of 2 MB. But with the following lines in file 'server.cfg', a data cache on hard disk can be defined.
regcache {
file { regcache }
size { 900 }
}
With the above example a file with name 'regcache' and size 900MB would be created after restarting of iXOS-JUKEMAN service. If no filename (with drive and path) is given, then the RAM would be used for data caching, thus the size should be set carefully.
On Windows NT you should use the Administartor GUI instead of editing the file 'server.cfg' (Menu 'Configuration' -> Dialog 'Buffers and Caches').
If the selection 'No data cache' is removed, then it is possible to set file name ( including path and drive) and size of the cache file. The default button gives a suggestion.
Due to operating system limitations the size of data cache, directory cache and recordable filesystem buffer can not be more than 2GB.
In most instances new data will be written to the cache quite frequently, therefore the presence of a data cache does not guarantee an increase in data throughput. If the same data in not read in a consecutive manner then it is quite possible to decrease data throughput as a result of increased overhead.
With iXOS-JUKEMAN you can write CDs in batch mode or incrementally and transparently through the file system.
In batch mode you fill the jukebox with recordable CDs, reserve the jukebox recorder for writing, instruct the file system to insert one of the recordable CDs in the recorder, and write data on it as if it were a separate external recorder. Then you move the CD back and add it to the set of CDs visible through the file system. In short, you have visible data migration: you collect the data on the hard disk, write it to a CD, and it is presented through the file system. You reserve a drive by disabling it in the device description (see "Device Descriptions" in Chapter 2). This is described in more detail in Chapter 5, "The Writer."
With version 2.1, you can also write a CD incrementally and transparently, which means that after initialization you can copy or move files to a CD as easily as you move them to your hard disk. The only difference is that you have to flash the system buffer where the data is cached to actually burn the files onto a CD.
Note:Without a valid license key in the writer.lic file, you can't write more than 128 MB on a CD.
To enable transparent writing, iXOS-JUKEMAN needs a global file system buffer on the hard disk. You specify this buffer in
server.cfg (in NT you can use the GUI to specify the buffer; see "Configuring the Writable File System and
the Directory Cache with the Administrator Tool" later in this chapter).
fsbuffer {
file {buffile}
size {1024}
inodes {10000}
}
buffile file in the installation directory on your hard disk. You have to stop and start the server to initialize
a new buffer.
To determine the correct buffer size and number of files, keep in mind that each file or directory on an unfinished disc needs an i-
node and that the size should be sufficient to cache all data you plan to transfer via the buffer. Be sure to finalize all
incrementally written CDs before you change the size of the fsbuffer. Otherwise those CDs will be of
no use.
A typical command sequence is:
cdadm writer action=init
location=jb.dev,27 vname=vol
jb.dev to be a volume named
vol. You can create directories and files, and write data into files. However, everything you
create or write goes into the hard disk buffer.
cdadm writer action=flush vname=vol
cdadm writer action=finalize vname=vol
LongFileName as LongFileName not as LONGFILE.NAME;1 as defined by
ISO 9660. But iXOS-JUKEMAN can read the CD correctly.
testcd to make it visible again.
cdadm testcd jb.dev 27
Use the following commands for a transparent write:
cdadm writer action=init
cdadm writer action=init fs=fake,track
cdadm writer action=flush <vname>
cdadm writer action=purge <vname>
cdadm writer action=finalize <vname> [
The following flags are added to cdadm survey -v (or -s):
+S
| Size of the whole volume including free space. |
+B
| Amount of buffered data for a volume. |
+W
| Amount of data written to the disc. |
+w
| W+B (total amount of data for a volume).
|
+F
| S-W (free space on the physical volume).
|
+f
| S-w (available space for more data).
|
+T
| Number of tracks written to the disc. |
cdadm writer action=init <location> vname=<name>
creates a recordable CD file system on the specified CD. The CD will be recorded in up to 99 tracks.
location=device,slot where
device is the device description name and slot is the slot number.
Example: cdadm writer action=init
location=jukebox.dev,1 vname=CDR_001
If you do not have a CD recorder drive or recordable CDs, you can simulate the function of the recordable filesystem by using a ISO image on hard disk (see 'CDs on Hard Disk' in chapter 4). Defineable with the GUI (NT) or via a device configuration file:
device=image
drive=c:\temp\rfs.iso
The file rfs.iso has to exist and has to have a size greater than 64kB. After attaching the defined simulated device you can initialize a recordable filesystem with:
cdadm writer action=init location=isoefv,1
vname=<name>
The contents of the file rfs.iso will be overwritten, when the burning is simulated with the commands described below:
cdadm writer action=flush vname=<name>
flushes the buffered data for the recordable file system <vname> to CD.
cdadm writer action=purge vname=<name>
deletes all buffered data for the recordable file system <vname>.
cdadm writer action=finalize vname=<name>
finalizes an incremental CD.
To write a CD permanently, iXOS-JUKEMAN needs a global file system buffer on the hard disk. In the main dialog, open the Configuration menu and choose Buffers and Caches.
If no incremental file system buffer exists, specify the path, size, and number of i-nodes. The default directory is the
jukeman directory on the host. The number of i-nodes specifies the number of files or directories in the file
system buffer. Each file or directory on an unfinished disc needs an i-node.
Click OK to create the buffer and add an entry to server.cfg. Once it is created, you cannot
simply rename or move the file system buffer; you have to remove the old buffer and create a new one. Be sure the buffer is empty
since all stored data will be lost. Be sure to finalize all incrementally written CDs before you change the size of the
fsbuffer. Otherwise those CDs will be useless.
The directory cache configuration is analogous to the recordable file system configuration. Check "Directory Caching on a Hard Disk" earlier in this chapter to estimate the size of the directory cache.
If you click IncrementalFS in the Contents dialog, the Incremental File Systems dialog is displayed.
To use the recordable file system you must have at least one drive declared as a recorder drive (see "Configuring the Devices" earlier in this chapter).
Format: Click this button to format a WORM/MO disc.
Initialize: To write to a recordable CD you have to initialize it. A recordable CD appears in the list box as -badCD- or -empty-, XXX depending on your drives. Select it and clickInitialize. Enter a volume name; the CD is initialized to this name.
Now you can create directories and files and write data into files. However, everything you create or write goes into the hard disk buffer.
Flush: If you want the buffered data to be written to the CD, select it and click Flush.
Three small tracks are already consumed by iXOS-JUKEMAN after initialization, so most of the space on the CD is available for writing, but you cannot flush more than 96 times, since the number of tracks is limited to 99.
Finalize: If you don't want to add more data to the CD, finalize it by clicking the Finalize CD
button(cdadm writer action=finalize).
This converts the CD into an ISO 9660 file system, and makes it readable on drives other than those controlled by Jukeman .
After finalizing, the CD is invisible, so you need to run a CD test.
iXOS-JUKEMAN allows Macintosh computers to read CDs in a jukebox. To export the iXOS-JUKEMAN filesystem to Macintosh computers, the 'MacFileService' Module for WindowsNT must be installed. The Module can be installed from the 'Network' configuration dialog in the 'Control panel'.
If that service is installed, then a virtual volume can be created with the 'FileManager' (not with NT-Explorer!). Such a volume can be connected from the Macintosh client computers over a NT share name.
There exists in version 2.1 a restriction:
If CDs in a jukebox are changed, then the Macintosh client computers are not notified about changed or new CDs. Therefore the above explained 'volume' has to be recreated and the Macintosh clients have to perform a reconnect to the iXOS- JUKEMAN filesystem.
Under normal conditions, you should have no reason to read the log file. However, if the server fails, you will find an error description in the log file. If you need to have the server debugged, you will need the log file. If you are curious about what the server really does, try to read the log file.
The server writes log messages into logfile.txt in the installation directory.
These messages report errors, important events, and less important events. A level is assigned to each message. Important messages
have low levels, less important messages have high levels.
The server's log level defines up to which level messages are written to the log file. Messages with a level above the server's log level are suppressed.
The default log level is 4. Most messages up to this level, and some of the level 5 messages, are easy to understand. A typical message looks like:
3 3/29:1137:310@2\\.\p0b0t5 is JVC's WO-drive "XR-W1001"
The first number is the log level. This messages indicates the attachment of a subdevice; this is important enough for log level 3.
Then you see the time represented as month/date:hourminute:secondtenth. The next symbol specifies the type of process that issued the
command. The process symbols are:
| @ | controls a drive. It actually reads the data requested by clients. |
| % | controls a changer. For simple jukeboxes it may also control the drive. |
| ? | accepts NFS and adm requests and replies quickly or queues them.
|
| $ | accepts internal requests to support the native file system of the NT version. |
| # | schedules the requests from ? and $ and passes them to % and @. |
| & | creates and terminates @ and % processes upon request of #. |
| - | is a @ or % process during asynchronous task processing. |
| - | is a portmapper, started if the operating system does not run a portmapper. |
After the process type, a digit or letter may follow. Non-trivial requests that cannot be satisfied quickly from cache are assigned these digits or letters cyclically. This simplifies the task of tracing a single user request through the large log file of a busy server. A blank indicates that no specific request caused the action.
Finally, there is the individual log message. This may, for example, report that a specific piece of hardware was detected, or that the
server found a CD. CD names are reported in rr and pc format. A large class of messages are SCSI error reports:
2 3/27:0329:349 @ 7 \\.\p0b0t5: 28 00 00 00 02 9b 00 00 01 00
1 3/27:0329:349 @ 7 SCSI-Error in 28 - READ (10)
1 3/27:0329:349 @ 7 status=2 sense=3 - MEDIUM ERROR
1 3/27:0329:349 @ 7 ascode 0x14 0x00 - BLOCK NOT FOUND
2 3/27:0329:349 @ 7 ReRead (0x14d800+0x800) got after 1 fault
2 3/27:0329:349 @ 7 read after 2 attempts from x11r5
Here the server reports an error that occurred during a SCSI READ command on a CD. The first line reports
the complete SCSI command: 10 bytes that were sent to the drive. The next line reports the command key, 28 hexadecimal, with the
SCSI command name, the 10-byte version of the SCSI READ command. The next line reports the SCSI
status and sense key together with the meaning of the sense key. The next line shows the additional sense code reported by the drive
and its explanation as given in the vendor's SCSI manual or in the SCSI standard. If the hardware failed, this explanation should point
out which part of it failed and why. The last two lines are not part of the standard SCSI error message; they report that the server
retried the READ command and got the requested data in the second attempt from a CD called x11r5.
0x14d800+0x800 means the server tried to read 0x800 raw bytes at disk offset 0x14d14d800.