A FILE SYSTEM
Technical Field
The present disclosure relates to file systems used in memory devices.
Background
Several file systems used for storing data in memory devices. One such file system is the "Lightweight" file system in which each memory sector contains a header to indicate the status of the sector and multiple data records, each with its own header. This flash file system requires the implementation of a compacting operation in order to retrieve the space occupied by deleted files. The system uses a Linked list structure in which data and header share space together.
Another file system known as the "Tiny Flash file system" organizes the files within the flash in a contiguous one-way linked list with data and header sharing space together. In this file system also the deleted files space is available for use only after defragmentation has been performed. There is also the need for a boot monitor which occupies memory space.
Brief Description of Drawings
The disclosure is illustrated with the help of the accompanying drawings where:

Figure 1 illustrates the structure of a file system according to an embodiment of the present disclosure.
Figure 2 illustrates the structure of a global area (also referred to as LOFFS) of the file system according to an embodiment of the present disclosure.
Figure 3 depicts the structure of a file header of an existing or a new file to be added in the storage subsystem in accordance with an embodiment of the present disclosure.
Figure 4 illustrates the structure of a deleted file header present in the Deleted File header Area of the file system according to an embodiment of the present disclosure.
Figure 5 describes a flow diagram representation depicting intialization in accordance with an embodiment of the present disclosure.
Figure 6 is a flow diagram representation depicting addition of a new file into the file system in accordance with an embodiment of the present disclosure.
Figure 7 shows a flow diagram representation of deletion of a file from the file system in accordance with an embodiment of the present disclosure.
Detailed Description
Some embodiments of the present disclosure are described in detail with reference to the accompanying drawings. However, the disclosure is not limited to these

embodiments which are only provided to aid the understanding to the ordinarily skilled in the relevant art. In the accompanying drawings, like reference numerals are used to indicate like components.
The terms 'memory' and 'storage subsystem' imply the same meaning and have been used interchangeably throughout the disclosure.
The present disclosure teaches a file system to manage multiple files in a storage subsystem by optimum utilization of the area of the storage subsystem. A system comprising such a subsystem according to an embodiment of the present disclosure comprises a data area and a header area. The data area stores contents of one or more data files while the header area stores access parameters and status information for accessing each file individually. The header area further comprises a global area for storing global storage subsystem parameters necessary for initialization such as file occupancy parameters, data file storage area size and data validity check parameters. The header area also comprises individual file headers for each file. The origin of the data area is the first location of the storage area and it dynamically extends towards the last available storage location while the origin of the header area is the last location of the storage area and it dynamically extends towards the first available storage location.
All file headers (valid and deleted) are stored together to reduce overhead and enable faster access. Headers corresponding to deleted files having contiguous data areas are merged together to utilize memory efficiently.
The structure of a file system in accordance with an embodiment of the present disclosure is described in Figure. 1. It comprises a header area (101), a data area

(102) and an empty area (103). The header area (101) which starts from the end of the memory area and extends towards the start of memory area includes a global area (called LOFFS header) (101.1), individual file headers (101.2.1, 101.2.2,.101.2.n) corresponding to each undeleted file in the memory area, and
individual file headers (101.3.1, 101.3.2, 101.3.n) corresponding to each
deleted file (referred to as a "hole" hereafter) in the memory area. The Data area (102) contains data of all files and starts from the start of the memory area and extends towards the end of memory area. The empty area (103) corresponds to the space present between the data segment area and the header area (101).
The global area (201) also referred to as LOFFS of the file system according to an embodiment of the present disclosure is shown in Figure 2. It shows a single header common to all the valid as well as deleted files ("holes") present in the system. This header contains global storage subsystem parameters such as number of undeleted files and number of "holes" in the storage subsystem, and the address and number of bytes in the empty space region. It also contains Data validity check bytes (e.g cyclic redundancy check (CRC) bytes) to validate the data in the common (LOFFS) header. The detailed structure of the global area 101.1 according to an embodiment of the present disclosure is shown in Figure 2.
The first field (201) contains the version information of the file system. The second field (202) contains the number of valid files and the third field (203) contains the number of "holes". The fourth field (204) defines the start address of the Empty Space area. The fifth field (205) contains the number of bytes in the empty space area. This makes it possible to easily determine whether a new tile will fit in the available empty space before storing any data. The sixth field (206) stores the date of the last update of the header space, in a predefined format. The seventh field

(207) stores the time of the last update of the header space, in a predefined format. The Data validity check field (208) is used to check for any corruption in the file system. This Data validity check field is updated every time the Global area i.e. LOFFS is updated. Also while initialization i.e. booting up the Data validity check bytes is calculated and compared with the saved Data validity check bytes. A match with the saved value ensures uncorrupted data.
Figure 3 depicts the structure of a file header (300) pertaining to a particular file in accordance with an embodiment of the present disclosure. Addition of new file or data adds a new file header in the File header area. This header contains file information such as the starting address of the file data, the number of bytes in the file data, and an indicator of whether the file is valid or deleted.
The file header comprises the following fields:
File Data Address field (301) contains the address of the start location of the file data in the Memory Area.
File Data Bytes (302) defines the number of bytes saved in the Data Area for that file. This count includes the collective length of data, Data file name and reserved bytes.
File/Hole Indicator flag(303) defines whether the file is valid or is a "hole" (deleted file). One state of indicates a valid file, while the other represents a "hole".
Deletion of a file converts the file header into a "hole header" by changing the state of File/Hole Indicator flag (303) and swaps it with the header of latest added file.

In an embodiment, the data areas corresponding to two or more contiguous holes are merged together to form a single hole. Reserved bytes (304) are provided for customization and future releases.
Figure 4 depicts the structure of a Deleted file header (300) pertaining to a particular deleted file in accordance with an embodiment of the present disclosure. The "deleted file header" includes a Hole Address field (401) which corresponds to the address of the location where deleted file data is present, a Hole Data Bytes field (402) corresponds to the size of the "hole" in bytes. The "deleted file header" further includes File/Hole Indicator (403), which differentiates between a file header and a "hole header". One state indicates a valid file, while the other represents a "hole". Reserved bytes (404) are provided for customization and future releases.
The initialization i.e. booting function according to an embodiment of the present disclosure is shown in Figure 5 with the help of a flow diagram representation. On power-up ("booting"), information such as number of files, number of holes, consumed space, and remaining space in the storage subsystem i.e. the memory area is required. This information is available from the common (LOFFS) header whose address is saved at location "0x00" of the storage subsystem i.e. the memory.
At the time of initialization, the storage subsystem is in any of the following states:
Empty Memory: In this state, all the bytes are in default state. Hence all the bytes in Common (LOFFS) are in default state.

Memory with valid Data: In this state, valid data is present in the memory which is confirmed by matching the saved Data validity check bytes with the new value which is calculated during booting.
Corrupted Memory: In this state, Memory is corrupted which can be due to any of the following two reasons:
Bits corruption due to ageing of Memory — a rare phenomenon.
Power failure during up-gradation of the Memory contents.
Figure 6 is a flow diagram representation depicting addition of a new file in the storage subsystem according to an embodiment of the present disclosure. This process involves pointing to an available set of empty locations in the memory large enough to hold the file data, followed by data write operation and finally a header updation operation. Before adding a new file, the memory is in any of the following states
Empty Memory
Memory with data but no "holes"
Memory with data and "holes".
In all cases mentioned above, the data is first saved in the memory in an appropriate space followed by header updation.
In case 1 and case 2 i.e. for empty memory and memory with data but no "holes", the data is stored in the empty space and the header space is then updated. This involves creation of a new header for that file and appending it after the header of the last saved file.

In case 3 of memory with data and "holes", one or more "holes" in the memory are utilized to put the data. If the file data length is known in advance, a suitable algorithm (e.g. Best Fit) is used to determine the place for writing the data. If the size is not available in advance, the data is written at the location having the maximum available space.
The first step of the process 601, determines whether or not one or more "holes" are present in the memory. In the absence of any "holes", the address pointer is set to the beginning of the empty space in step 602. On the other hand, if "holes" are present, the availability of the new file data length is ascertained in step 603. If the data length is known, the address pointer is set at the beginning of location which is found by suitable algorithm (e.g Best Fit) in step 604. If the data length is not known, the address pointer is set to the beginning of the maximum capacity space available in the storage subsystem in step 605. In step 606, the data is saved in the storage subsystem at the location pointed by the address pointer. Finally, the header area is updated in step 607.
Figure 7 shows the flow diagram representation of the deletion of a file from the storage subsystem according to an embodiment of the present disclosure. This is done by updating the header area without disturbing the data space. The flag/hole indicator of the file to be deleted is changed to indicate that it is now a "hole" in step 701. The modified header is swapped with the header of latest added file in step 702. The possibility of merging two or more holes pointing to contiguous data sections in step 703 is determined. In step 704 these headers are merged to form a single space for utilizing space efficiently.

Although the disclosure of the flash file system has been described in connection with various embodiments of the present disclosure illustrated in the accompanying drawings, it is not limited thereto. It will be apparent to those skilled in the art that various substitutions, modifications and changes may be made thereto without departing from the scope and spirit of the disclosure.

We claim:
1. A system comprising a storage subsystem, said storage subsystem
comprising:
a. a data area for storing the contents of one or more data files; and
b. a header area for storing access parameters and status information for
accessing each file individually;
2. A system as claimed in claim 1 wherein said header area comprises: -
a. a global area for storing global storage subsystem parameters ; and
b. individual file headers.
3. A system as claimed in claim 2, wherein said global storage subsystem
parameters necessary for initialization are selected from the group
comprising: -
i. file occupancy parameters; ii. data file storage area size; and iii. data validity check parameters
4. A system as claimed in claim 1 wherein the origin of said data area is the first location of the storage area and it dynamically extends towards the last available storage location.
5. A system as claimed in claim 1 wherein the origin of said header area is the last location of the storage area and it dynamically extends towards the first available storage location.

6. A memory device comprising:
a. a data area for storing the contents of one or more data files; and
b. a header area for storing file information and status information for
accessing each file individually;
7. A memory device as claimed in claim 6 wherein said header area comprises:
a. a global area for storing global memory device parameters ; and
b. individual file headers.
8. A memory device as claimed in claim 6, wherein said global memory device
parameters necessary for initialization are selected from the group
comprising: -
i. file occupancy parameters; ii. data file storage area size; and iii. data validity check parameters
9. A memory device as claimed in claim 6 wherein the origin of said data area
is the first location of the storage area and it dynamically extends towards
the last available storage location.
10.A memory device as claimed in claim 6 wherein the origin of said header area is the last location of the storage area and it dynamically extends towards the first available storage location.
1 l.A method of storing data in a storage subsystem comprising: -

a. storing access parameters and status information for accessing each
file individually in a header area; and
b. storing data files in a data area;

12.A method as claimed in claim 11 wherein access parameters and status information necessary for initialization are selected from the group comprising: -
i. file occupancy parameters; ii. data file storage area size; and iii. data validity check parameters
13.A method as claimed in claim 11 wherein storing individual file parameters comprises merging of file headers for individual deleted files when the individual deleted files occupy contiguous data areas.
12. A method as claimed in claim 11 wherein said method further comprises updating header area whenever corresponding data area is modified.
13. A method as claimed in claim 11 further comprising detemiining number of files stored and available space in data area by obtaining the updated status and access information available in the header area without accessing the data area.