I am Xiaojie Yi, one of the GSoC students this summer. Here I will write about my progress in my project. To learn about my project, you can find my first blog here.
I write here to make my mentors and everyone interested in this project easier to catch my progress. Also, it would be appreciated if you’d like to give me some help when I get problems.
To talk about what I did during the latest week.
Things begin with deal with the XFS images from my mentor @CruxBox. Actually, it costs me sometime to get it work. 
I tried to find some guidelines/docs in haiku book and somewhere but I didn’t get it. CruxBox told me just to use it by run: jam run “:xfs_shell” path_to_img. Maybe I should ask for help earlier next time and then I would not waste too much time unnecessarily. (So post them here may be a good idea.)
Then about where it crashed. The structure in this image is like this:
fssh:/> cd myfs
fssh:/myfs> ls
.:
drwxr-xr-x 0 0 4096 2021-05-02 20:18:53 .
drwxrwxrwx 0 0 0 2021-05-27 16:15:30 …
drwxr-xr-x 0 0 19 2020-06-01 18:18:16 dir1
drwxr-xr-x 0 0 6 2020-06-01 18:18:01 dir2
drwxr-xr-x 0 0 4096 2020-08-17 01:36:22 dir3
drwxr-xr-x 0 0 8192 2020-06-30 14:51:02 leaf
drwxr-xr-x 0 0 4096 2020-07-06 12:46:36 blockorleaf1
drwxr-xr-x 0 0 4096 2020-07-06 12:47:09 blockorleaf2
drwxr-xr-x 0 0 4096 2020-07-06 12:49:50 blockorleaf3
drwxr-xr-x 0 0 16384 2020-07-13 20:43:23 nodeDir
drwxr-xr-x 0 0 12288 2020-07-13 20:46:06 bigleaf
drwxr-xr-x 0 0 8192 2020-08-17 01:34:53 leaf2
drwxr-xr-x 0 0 40960 2020-07-20 17:00:27 btree
drwxr-xr-x 0 0 28672 2020-08-17 01:36:28 nodeDir2
drwxr-xr-x 0 0 24576 2020-07-20 17:30:03 nodeDir3
drwxr-xr-x 0 0 20480 2020-07-20 17:31:38 nodeDir4
drwxr-xr-x 0 0 20480 2020-08-17 01:36:34 nodeDir5
drwxr-xr-x 0 0 475136 2020-08-17 01:36:46 bigtree
drwxr-xr-x 0 0 958464 2020-07-29 15:20:57 bigbigtree
drwxr-xr-x 0 0 2404352 2020-08-11 18:55:39 bigtree2
drwxr-xr-x 0 0 10678272 2020-08-13 15:48:20 bigtree3
-rw-r–r-- 1000 1000 471875 2020-08-16 23:10:26 perimetric_chapter_1_input.txt
Now we can’t access btree and all below it, but others would be fine.
CruxBox suggests me to work with the unmerged B+Tree now.
Fine, things back here(I was here during my application period) and hope we work out it this time! Besides, now I can use xfs_db(a test tool for xfs) even though I am not familiar with all inside it yet.
Update will be posted later. 
Help is also welcome on improving the documentation.
I had started to write some things down when I worked on btrfs but it is not very complete: https://git.haiku-os.org/haiku/tree/docs/develop/file_systems/overview.txt
Probably this should be updated to simplify the command for running the fs_shell with the one you used, at least.
Hi Adrien,
In my project proposal, I will do documentation work at the end of my project. But I believe trying to do possible work at the same time will also be a good idea.
Besides, in the txt from you:
# userlandfs
As a second step, it's possible to use the filesystem as part of a runing
system, while still running it in userland. This allows use of Debugger,
memory protection, and in general any kind of userland debugging or tracing
tool. When the filesystem crashes, it does not bring down the whole system.
Userlandfs can run the filesystem code using the same interface as the kernel,
therefore, once everything is working with userlandfs, running the filesystem
as kernel code is usually quite easy (and provides a performance boost)
It refers to haiku/src/add-ons/kernel/file_systems/userlandfs, right? But I am not sure whether should I know something about this now?
Yes, that’s what it refers to. userlandfs provides “real world” testing of the filesystem (you can easily open multiple files at the same time, for example, which is not so easy to do from the fs_shell).
It is documented here (very short documentation, and maybe not up to date): Running UserlandFS | Haiku Project
I think it’s not very useful to start with this yet, if your filesystem is not working well in fs_shell. fs_shell is a more controlled environment and that’s better for the first steps.
For me personally, the documentation is more important than the code because it allows other people to understand things. When there is no documentation, everyone spends time to understand how things work, again and again. It is a waste of time for new people asking a lot of questions because the answers are not written anywhere, and for existing contributors because they have to explain the same thing over and over again.
As you can see in the files I linked, the docs are not like writing a full book about what you’re doing. It’s just short notes on some important things. And even small improvements there can be of great help for everyone to understand how things work.
Long time no see. 
Mentor reminds me to post here. I think he is right, in this way people cared about this project can catch what happened~ Even though I think I really achived too little during last period. 
Firstly, I found it is not accurate later.
Actually, we can access more based on our latest patchset. It should be all fine except the longest one.
It is like this:
Then I tried to find way to fix this. Obviously, it is not a good idea, because I stayed there for even longer time afer I decided to do this…
I sent some emails to @CruxBox to ask for help. He is very nice and patient. Finally, I know we can not turn to add xattrs or do anything else now, but to fix exsiting patches. Just do like the first step in my proposal.
Then about patches got merged these days, actually most problems are coding style till now.
But we have learn about some usage of Haiku’s help class. BStackOrHeapArray/AutoDeleter, great way for managing momery with cpp!
I am still working for the exisiting 2 patches these days. Things are a little complex about them. For it is based on files and it seems not get enough check till now, so I think I need to check if there are something missing. So, step by step this time, work out the existing problems firstly!
And nice to tell that, I will have my summer vacation after 24, June! I plan to merge existing patches first, and so I can push my next period plan at that time.
Of course, I think I need check if there are more important things missing, in that way I should still focus on adding fix implementation.
Anyway, looking forward to better xfs!
Sometimes a lot of investigation is needed to understand something that turns out to not require a lot of changes. Sometimes you really have to go through this by yourself because there is no real good way to explain it otherwise. I think the result is still positive: better understanding of the current situation, and of the codebase architecture.
Recently I have helped review and finalize some of these pending changes to XFS. I think it’s progressing nicely there 
Hey, I see that there is one more patch to be dealt with (that will be B+tree files related).
I think after that you can look at the issue we have here with B+Tree directories:
This one is more important to me. With these two done, we can quickly move to xattrs and get those done as well. It’ll be fun.
Hi,
Glad to say I have finished my final exams 2 hours ago, now I can work for this project full time!
OK, I will.
Hi,
Let’s have a short conclusion here. And if someone has met the same situation or know why, I will be appreciated.
Good news is we got existing patches merged.
Bad news is, as mentioned many times, we cannot get the 2e5 one.
The details is:
I got 3 diffrent results here.
segmentation fault
it can exactly access 1e5, and return error for the rest
XFS module use trace to catch error, and we can place where it returns error, as one of the pictures I uploaded before:
https://discuss.haiku-os.org/uploads/default/original/2X/d/d4f2b2fecbb57365e3b7a6d65a2624a1fd9946ec.png
Sometimes, I cannot access any of them…
I don’t know if it just behaves like this on my machine, or if everyone is the same. Also, if I can I will use more way to test it, but I don’t know other ways now.
The most strange problem is why it is exactly 1e5. (When I use xfs_shell to ls the bigtree3, it exactly shows me 1e5/2e5.) And based one my little experience, segementation fault is often caused by bad useage of pointors or memory is not enough. But I don’t know if it is the same in the kernel.
I cannot get answers from xfs.org now, because our problem is specific now, it is based on current status of xfs on haiku. I am paying attention to the pointers to see if there is something wrong. But not much progress yet.
I then tried reading 200,000 entries and there was a small issue with obtaining the right address to the directory entry. This doesn’t seem like a big problem in terms of how much needs to be fixed (maybe only a few lines of code) but the issue is that no one from #xfs could help and the documentation clearly wasn’t as accurate. Perhaps, I’ll see if I can get other developers to help me out in this (Axel you reading? :P) ——from @CruxBox 's blog
I am always think of that: if the code’s logic is wrong, we would not even get small directories. But we can get small tests now, so it would not be that problem… But I am not sure if it is not right.
I’d like to share what I did to get the 3 situations, if someone wants to do the same thing.
First, you can download images here: Directory listing of https://mirrors.tnonline.net/haiku/projects/xfs
Then, run this under haiku/generated: jam run ":<build>xfs_shell" path_to_your_image
When you get a segmentation fault, the best thing to do is run your code in a debugger (for Linux, you can use gdb, on Haiku you can use our own app simply named Debugger). When the segmentation fault happen, it will catch it and allow you to print a backtrace. The backtrace tells you where the problem happened. From there it should be easier to understand what went wrong.
The steps would be something like:
You can also set breakpoints (to have the program stop when it reaches a specific line of code), run the code step by step, inspect the value of variables, etc.
If you are unfamiliar with gdb you can also try one of the various GUIs for it.
Good idea, thanks, I just used gdb and breakpoints under my IDE and editor like vscode to debug. Surprised to know there is the same tools in os 
, I will look at how to use it in haiku.
