CODEWITHSUNDEEP
javafilesystems
A D
A D

Reputation: 809

Storing file control blocks efficiently

I currently have an assignment to create a filesystem in Java. I am trying to implement it to be FAT-like. My concern is that I am not storing or reading each FCB efficiently. Each file has a FCB, which I currently have as:

 ___________________
|                   |
| size of file name |
|___________________|
|                   |
| file name         |
|___________________|
|                   |
| # of data pointers|
|___________________|
| data pointer #1   |
|-------------------|
| bytes to read     |
|-------------------|
| data pointer #2   |
|-------------------|
| bytes to read     |
|-------------------|
| ...               |
|-------------------|
| data pointer n    |
|-------------------|
| bytes to read     |
|___________________|

When I want to read the FCB, I do the following:

1. Get the first four bytes
2. Convert to int -> bytes in file name
3. Read that many bytes for file name
4. Read next four bytes
5. Convert to int -> number of pointers
6. Read 4 * number of pointers
    6a. Read address from pointer #1
    6b. Read number of bytes, starting from address

In the end, my filesystem will be stored as

 ___________________
| number of pointers|
|-------------------|
| FCB#1             |
|-------------------|
| ...               |
|-------------------|
| FCB N             |
|-------------------|
| Data              |
|                   |
|                   |
|___________________|

I am concerned that my overhead is going to be too expensive when storing the FCBs. Is this how I am supposed to do it, though, for FAT, or am I totally misunderstanding it?

Upvotes: 1

Views: 332

Answers (1)

Sparky
Sparky

Reputation: 14057

I suspect you may have slightly mis-understood a couple of things, or just need a little guidance in how to better structure your data. I detect several different types of data mixed together, and from experience, that can lead to confusion.

I've implemented a few file systems in my time, and I have found it very convenient to separate as much as possible the types of data into:

1. File data : the file's data.
2. File meta-data : tells you about the file data (where it is found, permissions, ...)
3. File system meta-data : tells you what's free to use and what is not

Depending upon the file system, there may be some overlap. For example, in a FAT based FS such as that used by DosFS, the disk is essentially divided into two parts--the File Allocation Table (FAT) and the data space. The FAT is simply a table of entries that identify which clusters (disk blocks) in the data space have been allocated. However, to help conserve memory it utilizes a couple of tricks ...

1. Each cluster in the data space maps to a unique entry in the FAT.
2. The FAT entry contents identify the NEXT cluster that contains data (it's a linked list).
3. Special FAT entry values are used to mark a free entry, and the end of the chain.
4. Each cluster is the same size.

Directories, can be thought of as special files that follow special rules. Depending upon the FS, directory entries may be of fixed size, or variable size. In the case of the FAT based DosFS using the classic 8.3 naming convention, each entry is the same size. A directory entry must provide you with the means to discover the file name, where to begin finding its data as well as where to find its property data (such as file size and permissions). Some will store all this information directly as part of the entry, others will tell you where to start to find it.

I hope this helps.

Upvotes: 2

Related Questions