About :: TODO :: Blog :: RSS :: Old blog :: Projects :: GIT :: Gallery :: Notes

Tue, 13 Dec 2005

Crap


It looks like receiving zero-copy will put it's dirty hands into the Holy Grail of Linux FS - journaling code aka JBD.
As far as I can see, one may not call ->prepare_write() several times before calling ->commit_write(), since journaling transaction, at least for ext3, is setup only for the first requested number of blocks, i.e. when zero-copy code first time grabs a page from VFS and calls ->prepare_write() for that page, journaling code allocates it's structures and reserves number of blocks according to inode state, if zero-copy grabs next page and calls ->prepare_page() for that page again, no new blocks are reserved and only journal's reference counter is incremented. When ext3 then tries to do actual page preparation, it fails since journal_dirty_metadata() which only counted bocks for the first page. This happens every time I run zero-copy test without any logs, but did not happen, when there were tons of messages written to serial console, so this process seems to race with journal committing code.
At least this is how I can describe permanent assertion failure at fs/jbd/transaction.c:1114: "handle->h_buffer_credits > 0" when running without slow debug output.

Thinking in expansion way I started to hack in ext3 code, i.e. I do not understand why things happen in this or that way, but try to change some simple stuff based on assumption about above journaling problem. This is very wrong way, but I want to test networking stuff first and then switch to the different problem, so backing storage can wait.

:: Link / Comments (0)