Warning, this is cartoon drawing, I'm not a file system expert, I know just enough to be dangerous. So, a drive cannot distinguish user data sector transfers from file system sectors. They can try, but there's nothing special about the commands that are delivered to the drive when the file system is doing its updates to keep track of files, and when you do an f right and see and write a bunch of data to a file on the drive, just looks like another read and write command to the drive. So, these sectors are used to store user data, contents of our files, in the file system data, this is directory structure, and a bunch of file metadata. This is the image I've always had in my head. It's been augmented a little bit with my experience working in the storage industry, as it's not precise by any means, but it will give you the idea of what's going on. So, when you create a file originally, a file handle is created. Do a f-open with write permissions, file handle is created and handed to you in the operating system, stores these file handles in some kind of a table, could be a linked list data structure, doesn't matter, point is, it has a list of files. You've all run Linux before, you've all used Linux? Yes. Have you ever run LSOF? List of open files, and you get this big list. Well, it's cruising through this table, it's cruising through whatever this data structure is, and it's telling you stuff about all the files that are currently open right now. I've used it a bunch over the years for debugging different problems with servers and so forth. So, these handles really point us to a data structure that contain the file name, the directory path, permissions, and Linux has read-write execute permissions, another one is file position, where current file pointer is. If this was object-based file system, the ID of the object would be in there, in addition to these other metadata. I'm sure there's quite a bit of other metadata. So, every handle points to the structure. Somewhere in this structure is a pointer to an extent list, which is a link list of LBA's that make up a file. Some of thees can live in memory, and some of it can be out on the disk, and it really depends on the operating system implementation of how many of these extent lists that it wants to bring in and keep resident, in memory at one time. For speed, certainly it doesn't want to bring them all in at one time, but it may bring in some of them. So, your file is described by a linked list of logical block addresses that point to the sectors on this storage media that make up your file however big that is. So, some of them are in memory, and some of them are stored out on disk, and it wouldn't surprise me at all, but it was a doubly-linked list because you want to think about how f-seek works, you can move the file pointer back and forth. So, you need a way to rapidly move and traverse that list of LBAs back and forth, as you move the file pointer back and forth. That's the extent of my understanding of file systems, and what's really going on low level, in terms of what the drive sees, and what's being maintained by the operating system.
