[haiku-development] Re: Reg. XFS Implementation
- From: "Adrien Destugues" <pulkomandy@xxxxxxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Fri, 20 Mar 2020 12:11:03 +0000
20 mars 2020 09:30 "Shubham Bhagat" <dmarc-noreply@xxxxxxxxxxxxx> a écrit:
Hi,
I recently hit a roadblock trying to implement XFS with read-only
functionality.
While the specification for the file-system is available
(https://mirrors.edge.kernel.org/pub/linux/utils/fs/xfs/docs/xfs_filesystem_structure.pdf),
the
only official source code available is in Linux.
While looking into implementing the B+Trees, I realized that to understand
the algos implemented,
I'll need to understand linux buffer cache, page cache, resource sharing /
locking, filesystem VFS
interfaces. I am not entirely sure if it's the best approach.
I personally find reading Linux sourcecode is never the right approach to
things.
I'm looking at the specification and the base structure for the B+Trees seems
to be nothing fancy:
https://xfs.org/docs/xfsdocs-xml-dev/XFS_Filesystem_Structure/tmp/en-US/html/AG_Free_Space_Btrees.html
It's the typical implementation of a B+Tree. By itself, it is not related to
caching.
It's possible to implement the whole filesystem without any caching first.
Then, in Haiku,
there are two levels of caching relevant to this:
- The block cache, which is at the disk level and available for filesystems to
use (keeping
often-used blocks of disk data in memory so you don't have to read/write them
to disk all the time
- The file cache, implementing higher level of caching, which is related to the
vfs layer. This one
caches file data and metadata.
The main interaction with both caches for the filesystem is knowing what's
stored on disk ony,
what's stored in both disk and cache, and what's stored on cache only (or
modified there and not
written back to disk yet).
I don't think modelling the behavior on what Linux does for this is of much
help. Their caching
strategy is probably different. Also, because the filesystem is read-only for
now, a lot of things
are simplified (there is no data that is in the cache only). So eventually it
ends up with this
pretty simple things:
- The application wants to access file data or metadata. Is it in the file
cache? If not, get it from filesystem.
- The filesystem needs to read a block at some offset in the disk. IS it in the
block cache? If not, get it from disk device.
That's basically the idea of file and block caches. The only thing to add is
telling the caches when
something should be kept there, or when it's fine to remove it from the cache
because it won't be
used anymore (for example, a file that is now closed so there will not be
further accesses to it).
--
Adrien.
Other related posts:
