0

In a FAT-based file system design, the 'seek' involves traversing the links present in the FAT table, like in a linked list. It moves the current pointer within the file (pointed to by the file descriptor) forward by a distance of, say 'O' offset bytes. For very large values of O, this can be quite inefficient due to a multi-step traversal within the FAT table. Could we somehow augment the FAT table structure to improve the performance of seek operations. Is there already some methods dealing with this? Also, how are offset sizes greater than the file size handled to avoid end-of-file errors?

Helium Ark
  • 11
  • 2
  • I'm not sure since I never implemented a file system or file system driver. I would say that the seek method doesn't read the "fat table". It instead will just seek in the currently opened file. This is why there is also an "open" method. The open method will return a pointer to the beginning of the file and then there's no need to find the file again. Just seek in the currently opened file (that you know the position of already). – user123 May 12 '21 at 01:25
  • Hard-disk are not like main memory where the memory is split into different locations. Files are stored on hard-disks contiguously. Once you find the file on the hard-disk. You have its beginning position. To seek, you just need to add an offset to this beginning position. – user123 May 12 '21 at 01:27
  • @user123 I read that even in hard disks, files are not stored contiguously. They are split up, and the various regions are connected together as in a linked list in the FAT table. – Helium Ark May 12 '21 at 04:07
  • This is probably right but anyway the file is opened so seeking isn't as expensive as opening the file. I'm pretty sure the open method will "get" the file. The seek method will just seek in that opened file to a certain position. – user123 May 12 '21 at 06:32

0 Answers0