/images/head.jpg

On my 33rd Birthday

How time flies! I am 33 years old now and have lived in US for more than 10 years. I have also graduated from University of Utah for almost 5 years now. Wahoo! Each week passed very quickly. Now is the time to pause a little bit and reflect what has been achieved and what could be done better.

Achievements

  • Worked on a few projects/papers and made a few submissions to FAST/ATC/HotStorage, though none of them have been accepted yet. The D3 paper gets very close to be accepted by ATC18.
  • Mentored four interns. Really enjoyed working with some of them.
  • Learned a few new things: AWS S3/Azure, Golang, AWS serverless, and Spark.
  • Successful collaboration with a few faculties, include Haryadi Gunawi and Feng Yan.
  • Submitted the greencard application, though still waiting for VISA for approval.
  • Bought a house at Fremont, CA and moved in in February this year.

Areas to improve

  • Make a career plan and see where you want to go in the next ~5 years and work diligently toward the goal.
  • Systematically build your knowledge about storage systems. Read more documents/source code of existing storage techniques and systems. Do more hand-on experiments, trying/implementing these techniques/algorithms. Learning on the way.

Flush data to stable storage in C

When writing to a FILE object in C, it turns out there are multiple steps one needs to take in order to flush data from an application buffer to the stable storage (disk).

Assume we have a FILE object pointer, called fp. After the fwrite(fp) call, one first needs to call fflush(fp), to flush the application buffer to the OS kernel page cache. Since the data still sits in the OS kernel space, it won’t survive on a power lose. To flush the OS page cache to the stable storage which will survive a power lose, we need to further call fsync(fileno(fp)). fsync() will make sure to flush the data in the kernel to the storage media.

Notes for Myself

  1. When substantial changes have been made to a software, review the changes once before running the code. In most cases, you will be able to identify simple bugs/errors/typos in your code by just reviewing your code once. Jump directly to run and debug your code will probably take you more time to fix the program.

  2. Learn one piece at a time.
    When learning a new thing, it could come with many new concepts, making it harder to understand all at once. In such cases, try to understand one concept well, then move on to the next one. This reduces what needs to be understood at one time and makes it easier to learn. 分解敌军,各个击破。

Dynamic Kernel Debugging

  1. Compile kernel with CONFIG_DYNAMIC_DEBUG=y

  2. Mount debugfs, if not mounted yet

     sudo mount -t debugfs none /sys/kernel/debug
    
  3. Turn on debug for a specific module

     echo 'module pblk +pfl' > /sys/kernel/debug/dynamic_debug/control
    

The flags are:

	p    enables the pr_debug() callsite.
	f    Include the function name in the printed message
	l    Include line number in the printed message
	m    Include module name in the printed message
	t    Include thread ID in messages not generated from interrupt context
	_    No flags are set. (Or'd with others on input)