Browse Prior Art Database

A method for network client file system to support concurrent readers and writers

IP.com Disclosure Number: IPCOM000020337D
Original Publication Date: 2003-Nov-13
Included in the Prior Art Database: 2003-Nov-13
Document File: 1 page(s) / 40K

Publishing Venue

IBM

Abstract

Concurrent Input Output

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 86% of the total text.

Page 1 of 1

A method for network client file system to support concurrent readers and writers

Network file system clients such as support access to things like databases that do their own locking. This locking is much more granular than the gross level of the file system inode lock. Network file systems have a concept similar to the INODE lock of a file system so that there can only be a single writer at a time. There are databases that share all which coordinates across multiple nodes for reads and writes. There are databases that share nothing. There is no concurrent access to data between database nodes.

The idea of this discussion is "concurrent readers and writers" to the client network file systems .

The summary is made with the following points:

The mount on the client could query the server for the mode of the file system on the server. For network file systems the VNOP_FINFO (vnode operation, file info) vnop call would return that the server is in CIO mode (Concurrent I/)). The client mount would thus inherit the CIO mode from the server. The mount or open options on the client could just affect the client IO and not the server IO. If the client is in CIO mode the client takes advantage of concurrent readers and writers. If the server is also in CIO mode then both sides client and server allow concurrent readers and writers. The remote mount of a file system that is in CIO mode allows the server to avoid the lock penalty but not the client.

The cool thing here is ha...