Browse Prior Art Database

Managing Open Handles on a Per Session Basis in 386 HPFS

IP.com Disclosure Number: IPCOM000106348D
Original Publication Date: 1993-Oct-01
Included in the Prior Art Database: 2005-Mar-21
Document File: 2 page(s) / 51K

Publishing Venue

IBM

Related People

Lillie, BT: AUTHOR [+2]

Abstract

Disclosed is an extension for the 386 HPFS file system that is a part of the OS/2 LAN Server 3.0* product which runs on OS/2 2.0*. The 386 HPFS file system includes a Ring 0 server which communicates directly to the file system, bypassing the OS/2 kernel. The server component of the 386 HPFS file system manages all file handles from a set of arrays shared among all remote requesters. Likewise, the server manages all search handles from a set of arrays shared among all remote requesters. The file handle is returned to the remote requester in a 16-bit (13-bit for searches) field in an SMB, which is what LAN Server uses to communicate with requesters. Since the handle is a 16-bit value, there is a limit to the size of the arrays. Also, since only one array (i.e.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 59% of the total text.

Managing Open Handles on a Per Session Basis in 386 HPFS

      Disclosed is an extension for the 386 HPFS file system that is
a part of the OS/2 LAN Server 3.0* product which runs on OS/2 2.0*.
The 386 HPFS file system includes a Ring 0 server which communicates
directly to the file system, bypassing the OS/2 kernel.  The server
component of the 386 HPFS file system manages all file handles from a
set of arrays shared among all remote requesters.  Likewise, the
server manages all search handles from a set of arrays shared among
all remote requesters.  The file handle is returned to the remote
requester in a 16-bit (13-bit for searches) field in an SMB, which is
what LAN Server uses to communicate with requesters.  Since the
handle is a 16-bit value, there is a limit to the size of the arrays.
Also, since only one array (i.e., one "set" of 16-bit values) is used
for all requesters, there exists a limit of 64K file (8K search)
handles the server may allocate.

      Because a single key is limited to the size of information that
it can address, the addition of a second key will permit a greater
number of handles to be available on the server while restricting the
ability of a client to use all of the handles available.  Since the
requester's session ID is used as the second key, the server will be
able to provide each requester its own set of 16-bit values, i.e.,
64K handles.

      This introduces potential gross over-consumption of memory if
the current sch...