I have read your proposal. I think you can go a little deeper in technical details. For example, you could explain how the journal is updated, what kind of information is stored there, maybe how the journal interacts with the file and block caches to make sure consistent data is written to disk and we don’t end up with a corrupted filesystem?
Some notes about the different types of nodes, extents, allocation groups, and the related challenges for the write support would also be interesting.
Thanks a lot for the TRACE tip, that actually clarifies a big part of how to chase this down.
I also spoke with @Mashijams, and he mentioned that he already has a patch related to big timestamp support. So I think I’ll leave this issue for now and pick up another TODO to work on instead.
Got it, I’ll refine the proposal and add deeper technical details in the overview, breaking things down clearly at each stage.
At the same time, I’ll pick another TODO to work on. After finishing both the proposal improvements and the TODO, I’ll go ahead and submit my GSoC application.
Do you think I might have overlooked anything else, or does everything look on the right track now?Thanks a lot for your time and guidance, I really appreciate it.
The proposal seems good, you can continue to update it as you understand more of the code. But you can focus on code contributions and see how far you can get the fs_shell to work.
ok I’ll keep refining the proposal as I go, but shift my focus more toward code contributions and pushing fs_shell further. I’ll also keep you updated on my progress and what I’m working on.
I have completed my proposal and added a new section on notes and write support challenges, as you suggested.
I will now submit my GSoC application and focus more on studying the codebase and contributing code. I may not be able to work intensively due to my midterm exams until April 2nd, but I will do my best to make as much progress as possible on the project.