I’m trying to understand how fs works and from the looks of it, we either use existing libraries (libntfs) or not use and make our own like btrfs/xfs. The code here
src/add-ons/kernel/file_systems/<> specifies how to read/write for the fs type in question.
I had few doubts:
- Where is the driver code that actually writes to secondary memory? As I understand, to write to fs, we need to access the driver through an interface right (like SATA).
- Intuitively, I imagine kernel caches writes to secondary mem in a buffer and does them in batches. Is that so?
Don’t know any haiku specifics but mot fs drivers will write to a block device and the block device driver deals with writing to the underlying medium. But not always true, for example fuse is arbitrary and network based fs will make network connections. Conceivably you could also have e.g. a filesystem over a serial line (character device).
Not directly in the filesystem.
Your filesystem can be using data from a disk, sure, but it could also be an image file, or a RAM disk. And even if it’s a disk, it could be SATA, but also NVMe or SCSI or SD/MMC. Fortunately, the filesystem doesn’t have to worry about that, that’s the job of the disk device drivers.
The access to the data is done using a file descriptor and the usual read() and write() calls, although, since there is a lot of random access, you will typically find read_pos() and write_pos() used instead (they are just a combined seek and read or write). Here is one example in the UFS2 driver: Volume.cpp « ufs2 « file_systems « kernel « add-ons « src - haiku - Haiku's main repository
To manage opening and closing the device, DeviceOpener.cpp « shared « file_systems « kernel « add-ons « src - haiku - Haiku's main repository can be used.
There are two types of caches used: file cache and block cache. The file cache sits “above” the filesystem, files that are cached there are accessible by apps without ever accessing the on-disk filesystem at all. The block cache is in between the filesystem and the block device, and allows frequently accessed parts of the underlying block device to be cached in RAM. The caches are implemented here: cache « kernel « system « src - haiku - Haiku's main repository
They are both optional: some filesystems do not use caching at all yet, or, in theory, they could implement their own caching.