OSDev.org

I would like to understand how the ntfs (file system) of a SATA hard disk drive collaborates with the sata protocol. I mean that how the ntfs translates and eventually sends sata commands to the hardware of the drive.

SATA and NTFS are almost completely unrelated. NTFS describes the on-disk representation of files and their metadata, and can be used with any type of device. SATA defines the electrical and signalling specifications to connect a disk to the computer, and is usually coupled with AHCI to allow the OS access to the disks.

In most OSes, the filesystem driver (NTFS, FAT, ext2, whatever) will communicate with the block device driver (SATA, IDE, USB, raw file, etc) via some common interface.

thepowersgang wrote:SATA and NTFS are almost completely unrelated.

Scratch "almost".

We had NTFS before there was SATA. And a SATA drive would work just as well with ext4 or whatever filesystem you'd toss at it.

Ok lets say that we want to write 1000 bytes in sectors 3 and 4. How the ntfs can understand this?

It doesn't. NTFS is a filesystem, not a hardware device driver.

NTFS needs to decide where the data for a file is to be placed, rather than be instructed where to put it.

As far as i can understand when you decide to write a file in a disk ntfs is responsible to do it. But how decides where to put it?
And the sata protocol how is implemented?

diama13 wrote:As far as i can understand when you decide to write a file in a disk ntfs is responsible to do it. But how decides where to put it?
And the sata protocol how is implemented?

NTFS is proprietary. There's little info available. You need to peek at open source drivers to get an insight. And as far as SATA is concerned, we have a wiki for a reason. Explore it.

What i mean is that if i want to save a file in a hard disk the ntfs will do this job for me. Ok with that. But when these data arrive at the disk driver how will understand which sectors has to fill with the data?

diama13 wrote:I would like to understand how the ntfs (file system) of a SATA hard disk drive collaborates with the sata protocol. I mean that how the ntfs translates and eventually sends sata commands to the hardware of the drive.

NTFS is a filesystem, while SATA is a protocol for reading/writing sectors to/from a disc. NTFS doesn't use SATA directly, rather goes through some type of virtual filesystem implementation. That way, NTFS both can work with SATA, IDE and USB discs.

diama13 wrote:What i mean is that if i want to save a file in a hard disk the ntfs will do this job for me. Ok with that. But when these data arrive at the disk driver how will understand which sectors has to fill with the data?

you'll have to be a bit more precise than "how will understand", how will what understand what.

The filesystem decides by its logic (either proprietary, or documented as with ext2/3...) where to put the file. It tells the disk controller. The disk controller then acts as required.

Sorry SDS. I imagine that i can't find these logic or virtual filesystem implementation(as rdos said) for my seagate hard disk drive???

http://wiki.osdev.org/VFS
http://wiki.osdev.org/File_Systems

The fact that it is a seagate hard disk will have absolutely no bearing on the filesystem. Although it may be relevant for the disk driver.

I write an app and i decide to save a file in my disk. The ntfs examines if there is enough space in the disk to write the file? An if so i still cannot understand which level decides where the file will be written. Sorry.... I will try more to understand and if i have further questions i will come back. Thank you all!!!

One can't put it much better than berkus did, but I will try.

The application is unaware of any technical details. All it has is a "file name", which is opaque to the application (i.e., the application doesn't know what "C:\Data\MyFile.txt" or "http://www.example.com/MyFile.txt" or "/mnt/foo/MyFile.txt" actually mean). The app can use this "file name" to make an API call to the OS in order to do something with this file (i.e., fopen(), with subsequent fprintf(), fgets(), fclose() etc.).

The Virtual File System is part of the OS, and it is the part that actually figures out what the "file name" means. Set up during boot time, and constantly updated as the system environment changes (e.g. through USB sticks plugged in, network shares being registered etc.), this is the part that "knows" that "C:\Data\MyFile.txt" is handled by file system A, "http://www.example.com/MyFile.txt" is handled by file system B, and "/mnt/foo/MyFile.txt" is handled by file system C. While being ignorant of what those file systems mean, the VFS does the mapping of the application's calls (fopen(), fprintf(), fgets(), fclose()) to the corresponding file system instances (fs_A->OpenFile(), fs_B->PrintToFile(), fs_C->ReadFromFile() etc.).

File Systems are instanciated for every partition, network share etc. registered with the system. You might have an instance of NTFS for "C:\", an instance of HTTPReader for "http://", and an instance of ext3 for "/mnt/foo". The file system "knows" how to turn the "raw" data from the application into the appropriate requests to the drivers involved. HTTPReader "knows" how to turn an fopen() into a HTTP request, but doesn't know whether the connection it was registered for is TCP/IP, TokenRing or SomethingElseEntirely. NTFS "knows" how to register a new file with the containing directory, but doesn't know whether the storage it was registered for is a SATA drive, a SCSI drive or a floppy drive. All it knows is that the storage has X sectors, Y of them already filled, in which sector the root directory resides and how to go from there. It will figure out that the write to "C:\Data\MyFile.txt" requires reading this sector to figure out the write should go to that sector, but it doesn't know how to do those reads and writes. It passes them to the...

Device Driver - the piece of the OS that "knows" that, in order to read sector X from a SATA drive, it has to set this register just so and then trigger this interrupt, then wait for that interrupt before getting the data in that memory location. Or whatever hoops the SATA controller requires you to jump through.

I hope this makes it a bit more clear.

So you say that ntfs cannot know where the data have been stored in the disk(e.g. in which sector of the disk). And how the device determines that? That is if the device receives a write request from ntfs in which position(sector) will store them?