XFS : Project Progress

Development
#1

Hello Haiku Community!

I am Raghav Sharma (Mashijams) and I am happy to share that I am selected as GSoC mentee for xfs filesystem support project.

My mentors are Pulkomandy and Salony.

Here is the link to my project proposal https://drive.google.com/file/d/19G6SUUh4HUKpvAoEg6C0fHsDqBvVbfLa/view?usp=sharing

In this forum I will keep my mentors and community updated about my project, what I am currently doing, asking for help etc…

Thanks for selecting me as GSoC student :slight_smile:

Looking forward to having an amazing learning experience with Haiku.

15 Likes
#2

Welcome @Mashijams , good luck on your GSoC project!

1 Like
#3

Community Bonding period started, I got familiar with haiku implementation of xfs during my application period and after it as well.

After my application period I did mostly research and read lots of documentation and prepared a roadmap for easing project development.
I will very soon upload that on Haiku Trac in form of tickets and comments so that others can get a good Idea as well.

Anyways here is what I will be starting to work from today :

  1. Implement xfs version 5 superblock.

  2. Get crc32 checksum table and implement ck_sum (I will take inspiration from its linux implementation) function for metadata checksumming.

  3. Test if we are getting valid version 5 superblock on mounting filesystem image and fix bugs/issues that comes.

After this I believe we should be able to detect valid super block for both xfs version 4 & 5.

1 Like
#4

Welcome Mashijams. I wish you success and fun working on your GSoC goals!

I think it would be better if you created personal blog posts for your progress reports and only open threads on the forum for questions and generel discussion. That way it will be easier to follow your work, also in the years to come. If someone wants to get an overview on the xfs GSoC project, they’ll just check your blog and get all the info.

To create a block, clone Haiku Website GitHub and see the scripts newblog.sh and newpost.sh. Then create PRs.

3 Likes
#5

Yes good suggestion
I will start it by writing an introductory blog.

5 Likes
#6

Hello Mashijams, nice to have you working on xfs !

2 Likes
#7

Hello Everyone,
Xfs version 5 requires metadata checksumming with Crc32c, which is common for many filesystems.
I will be importing code from this https://web.mit.edu/freebsd/head/sys/libkern/crc32.c implementation of it.

What is the correct way to include it in our xfs code?

As of now I simply created header file “Crc32c.h” which includes all the code above and then used it in checksumming functions, but I think this may not be very correct way.

I think we can have better discussion by directly looking at code on gerrit for review, so I will try to push patch very soon ( After completing work of super block ).

#8

I think we already have an implementatio somewhere, atleast for btrfs
src/add-ons/kernel/file_systems/btrfs/Inode.cpp#L468

#9

Btrfs uses crc32 I guess(?), what we need is crc32c calculator.

#10

Actually I got it.
Calculate_crc32c is implemented by ext2 filesystem support on Haiku.
I will try to import it now for XFS as well.

#11

You can move it to a shared file in shared\file_systems\kernel\add-ons\src - haiku - Haiku's main repository

It looks like ext2 and UDF may share some code too?

2 Likes
#12

Is it better Idea to move it to shared file?
We might need to change it little bit to work for xfs_shell and its possible it may not work for other file systems.

#13

It depends what needs to be changed, is it the same CRC algorithm or a different one?

#14

Yes its the same crc algorithm.
Actually what we need is this function (crc32.c file) crc32.c\ext2\file_systems\kernel\add-ons\src - haiku - Haiku's main repository

This function definition is in this header file CRCTable.h\ext2\file_systems\kernel\add-ons\src - haiku - Haiku's main repository

It contains some system headers which will give errors when compiled on xfs_shell.

#15

As noone has mentioned this:
Whenever we import foreign dependencies it is good to point at exactly where and what version/tag/git revision the code come from. It makes it so much easier for others to understand if it is ok, if we should upgrade and if it is secure.

So commits should always try to explain to the person coming after you where/why/how kind of thing.

3 Likes
#16

Ohk, will keep that in mind.

#17

Ok, in that case, I would say:

  • Move the files to filesystems/shared: crc32.c, CRCTable.cpp, CRCTable.h from ext2, and crc_table.c from the UDF filesystem (it was used to generate the tables in CRCTable.cpp)
  • Adjust the jamfiles for ext2 and udf to use these files from the shared directory
  • You can make a commit with that already
  • Then, see how to use the same code in XFS and make it compatible with fs_shell (which is a good idea anyway, if we want to make an ext2_shell or udf_shell some day).
3 Likes
#18

I think we should not move CRCTable.h to shared folder.
It will give error on compiling out ext2 code with no such file or directory “CRCTable.h”.

#19

Yes, moving the files will require adjusting Jamfiles:

  • add SEARCH_SOURCE rules to tell that some files are in the shared directory
  • adjust the include path to search in the shared directory as well

Some examples from other filesystems, which you can adjust depending on the files and paths you need:

# found in BFS
SEARCH on [ FGristFiles QueryParserUtils.cpp DeviceOpener.cpp ]
	+= [ FDirName $(HAIKU_TOP) src add-ons kernel file_systems shared ] ;
# found in btrfs
UseHeaders [ FDirName $(HAIKU_TOP) src libs uuid ] : true ;
2 Likes
#20

Wow, I didn’t knew about that Header file jam rule.
Thanks!
Everything works fine now and I submitted my commit for crc files :slight_smile:

2 Likes