1.4 Cautions

When using virtual files, you should be aware of the following issues:

1.4.1 eDirectory Name Formats

Older XML requires eDirectory™ names in backslash format. For example

\novell_inc\novell\prv\nss\randys

However, in VFS, you can enter eDirectory names in any format and it is changed internally to the backslash format.

You can input names in the following eDirectory container format (with or without the leading dot):

.cn=admin.o=novell

However, container format is not required.

1.4.2 Multiple Readers and Writers

To manage consistency, when virtual reads reference memory or a function, the results are put in a buffer that is specific to that instance of opening the file. However, this process means that if you close and reopen a file, the results from any previous commands are no longer accessible.

Also, read operations that start reading at an offset other than zero reference the results buffer without refreshing it. Read operations at offset zero usually refresh the read information. However, if it is a function-type datastream that does not specify a read function, you must write to the file to refresh the data.

1.4.3 Maximum Lengths

The results buffer is initially set to 8K. However, read and write operations can change the size of the buffer so that responses are limited only by the amount of free memory that is available.

The transformation template is compiled at the time it is written to the file and held in memory. Generally, the template does not use very much memory. However, “data” type datastreams can consume more memory than is initially set.

1.4.4 Read and Write Offsets

Because you are writing the virtual I/O commands to a file, by default the offset of any following read and write operations is set to occur just past the data that was supposedly written. VFS tracks the length of the virtual commands and adjusts the offset so that any succeeding read and write operations appear to start at offset zero.

You must be careful when you seek to an offset other than zero in a virtual file since the offset might not be where you expected it.

The file system examines incoming offsets. As long as these offsets are greater than the length of the original virtual I/O command, they are adjusted to account for that length. However, if an offset is ever less than the length of the virtual I/O command, the file system assumes that a seek has been performed and no longer makes an adjustment. All future seek operations to location zero start at the front of the data being rendered by the virtual file and all subsequent seek operations start at the actual position in the result buffer.

If you are going to read from a file without closing and reopening it, you should seek to location zero after writing to the same file.

1.4.5 Client-Side Caching

Due to the dynamic results of virtual files, no client-side caching should be performed on virtual files.

Any oplock requests are rejected for virtual files.

1.4.6 Device Sharing

If a device is shareable and you intend to use it in a cluster, you must manually mark the state of the device as shared (because Novell Storage Services (NSS) cannot automatically detect the intended use of a device). By marking a device “shared,” all partitions, NSS storage pools, and NSS logical volumes created on that device are automatically marked “shareable for clustering.”