Hi Chao,

[snip]

> > We can see that file still uses 16 Blocks
> > 
> > How do we deal with such situation?
> 
> Now, f2fs does not convert non-inline inode to inline one for these potential
> inodes with small size. So, once inline inode is converted, there is no
> procedure to revert it.
> 
> > it's meaningful to reuse inline_data?
> 
> Actually, I did not know the history reason why we don't implement the
> reverse procedure, as inline_data feature is designed and implemented
> by Huajun and Jaegeuk. I can't find any clues in old threads.

Initial proposal implemented this sort of conversion.
But, in the production level, I suffered from many bugs like eating data.
The major attack to me was the lock coverage which was not fully designed
concretely.

The real complexity lied on allocation and truncation paths in parallel.
And, it turned out the key data structures was not covered by a lock correctly.
So, I changed them not only to use node page lock as much as possible, but
also to implement one-way conversion to reduce lock contention, inline_data
conversion overhead, and code complexity.

In addition, the reason why I decided to do that is from the question how many
large files are converted to small-sized (1B ~ 3.5KB) files.

In terms of life of files, I believe it is enough to set inline_data for
originally small files, which mitigates cleaning overhead as my expectation.

For space utilization, I'm not quite sure since most of space are normally
occupied by many large files for multimedia.

Let me correct, if I'm missing something.

Thanks,

------------------------------------------------------------------------------
_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

Reply via email to