The IQ application will be briefly unavailable on Sunday, March 31st, starting at 10:00am ET. Access will be restored as quickly as possible.
Browse Prior Art Database

Supporting "files cluster" for better performance, under the traditional file system

IP.com Disclosure Number: IPCOM000028660D
Original Publication Date: 2004-May-26
Included in the Prior Art Database: 2004-May-26
Document File: 1 page(s) / 39K

Publishing Venue



This disclosure's purpose is to propose an addition to the existing filesystem, such that a 'clustered files' feature can be realized without having any negative impact on other traditional applications. The proposed additional support can be utilized at the user's discretion, and as such is "backward compatible" and has no adverse effects.

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

Page 1 of 1

Supporting "files cluster" for better performance, under the traditional file system

Some applications need to access a number of files at the same time, for instance DB applications, which tend to read/write and modify a number of tables (files) in order to complete a logical transaction. In a traditional filesystem, there is no easy way (if at all) to have all these files clustered together. If they were together (i.e. in adjacent pages on the disk), the access time to the disk would be minimal in comparison to the time it might take to access them if they were scattered all over. Under these conditions, there are basically two approaches:

1. Accept the filesystem as is, and rely mostly on the caching mechanism, such that the hardening of the data is not done too often and thus it is not too costly.
2. Either utilize the 'raw' access to the underlying storage device and, in essence, maintain a specialized data structures/filesystem for that purpose, or utilize a similar method on a huge single file, and thus benefit from the filesystem logging and cache mechanism (which is not possible when the 'raw' methodology is used).

It is apparent that the best solution would be if the filesystem itself could enable and support a "clustered files" feature. That way, the physical layout of the files is guaranteed to be efficient from the I/O perspective, and at the same time the utilities that we are familiar with would be provided.

    If the "clustered files" do not grow or removed too often, and their life span is long enough, then it is justified to have them clustered. The "cluster file" feature might be a good answer for this class of applications. If the files do grow over time, we might lose the localization we have opted for, as the cluster will be "fragmented", but we will still be able to work with the files as...