All of lore.kernel.org
 help / color / mirror / Atom feed
From: Wu Bo via Linux-f2fs-devel <linux-f2fs-devel@lists.sourceforge.net>
To: Jaegeuk Kim <jaegeuk@kernel.org>, Chao Yu <chao@kernel.org>
Cc: Wu Bo <wubo.oduw@gmail.com>,
	linux-kernel@vger.kernel.org, Wu Bo <bo.wu@vivo.com>,
	linux-f2fs-devel@lists.sourceforge.net
Subject: [f2fs-dev] [RFC PATCH 0/5] Add inline tail support
Date: Tue,  9 Jul 2024 19:33:02 -0600	[thread overview]
Message-ID: <cover.1720515215.git.bo.wu@vivo.com> (raw)

The inode in F2FS occupies an entire 4k block. For many small files, this means
they consume much more space than their actual size. Therefore, there is
significant potential to better utilize the inode block space.

Currently, F2FS has two features to make use of the inode block space: inline
data and inline xattr.

Inline data stores file which size is smaller then 3.5k in inode block. However,
for slightly larger small files, there still have much waste.
For example, a 5k file requires 3 blocks, totaling 12k of space, which is
more than twice the size of the file itself!

Additionally, the end of a file often does not occupy an entire block. If we can
store the end of the file data within the inode block, we can save an entire
block for the file. This is particularly important for small files.

In fact, the current inline data is a special case of inline tail, and
inline tail is an extension of inline data.

To verify the benefits of inline tail, I have developed these preliminary codes.
To make it simple, inline tail only on small files(<64k). And the layout of
an inode block is following:

| inode block     | 4096 |     inline tail enable    |
| --------------- | ---- | --------------------------|
| inode info      | 360  |                           |
| --------------- | ---- | --------------------------|
|                 |      | extra info         | 0~36 |
|                 |      | **compact_addr[16] | 64   |
| addr table[923] | 3692 | reserved           | 4    |
|                 |      | **tail data        |      |
|                 |      | inline_xattr       | 200  |
| --------------- | ---- | --------------------------|
| nid table[5]    | 20   |
| node footer     | 24   |

I tested inline tail by copying the source code of Linux 6.9.7. The storage
space was reduced by approximately 8%. Additionally, due to the reduced IO, the
copy time also reduced by around 10%.

Wu Bo (5):
  f2fs: add inline tail mount option
  f2fs: add inline tail disk layout definition
  f2fs: implement inline tail write & truncate
  f2fs: implement inline tail read & fiemap
  f2fs: set inline tail flag when create inode

 fs/f2fs/data.c   | 61 ++++++++++++++++++++++++++++++++++++++++++++-
 fs/f2fs/f2fs.h   | 44 ++++++++++++++++++++++++++++++++-
 fs/f2fs/file.c   | 10 ++++++++
 fs/f2fs/inline.c | 64 ++++++++++++++++++++++++++++++++----------------
 fs/f2fs/inode.c  |  6 +++++
 fs/f2fs/namei.c  |  3 +++
 fs/f2fs/node.c   |  6 ++++-
 fs/f2fs/super.c  | 15 ++++++++++++
 8 files changed, 185 insertions(+), 24 deletions(-)

-- 
2.35.3



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

WARNING: multiple messages have this Message-ID (diff)
From: Wu Bo <bo.wu@vivo.com>
To: Jaegeuk Kim <jaegeuk@kernel.org>, Chao Yu <chao@kernel.org>
Cc: linux-f2fs-devel@lists.sourceforge.net,
	linux-kernel@vger.kernel.org, Wu Bo <wubo.oduw@gmail.com>,
	Wu Bo <bo.wu@vivo.com>
Subject: [RFC PATCH 0/5] Add inline tail support
Date: Tue,  9 Jul 2024 19:33:02 -0600	[thread overview]
Message-ID: <cover.1720515215.git.bo.wu@vivo.com> (raw)

The inode in F2FS occupies an entire 4k block. For many small files, this means
they consume much more space than their actual size. Therefore, there is
significant potential to better utilize the inode block space.

Currently, F2FS has two features to make use of the inode block space: inline
data and inline xattr.

Inline data stores file which size is smaller then 3.5k in inode block. However,
for slightly larger small files, there still have much waste.
For example, a 5k file requires 3 blocks, totaling 12k of space, which is
more than twice the size of the file itself!

Additionally, the end of a file often does not occupy an entire block. If we can
store the end of the file data within the inode block, we can save an entire
block for the file. This is particularly important for small files.

In fact, the current inline data is a special case of inline tail, and
inline tail is an extension of inline data.

To verify the benefits of inline tail, I have developed these preliminary codes.
To make it simple, inline tail only on small files(<64k). And the layout of
an inode block is following:

| inode block     | 4096 |     inline tail enable    |
| --------------- | ---- | --------------------------|
| inode info      | 360  |                           |
| --------------- | ---- | --------------------------|
|                 |      | extra info         | 0~36 |
|                 |      | **compact_addr[16] | 64   |
| addr table[923] | 3692 | reserved           | 4    |
|                 |      | **tail data        |      |
|                 |      | inline_xattr       | 200  |
| --------------- | ---- | --------------------------|
| nid table[5]    | 20   |
| node footer     | 24   |

I tested inline tail by copying the source code of Linux 6.9.7. The storage
space was reduced by approximately 8%. Additionally, due to the reduced IO, the
copy time also reduced by around 10%.

Wu Bo (5):
  f2fs: add inline tail mount option
  f2fs: add inline tail disk layout definition
  f2fs: implement inline tail write & truncate
  f2fs: implement inline tail read & fiemap
  f2fs: set inline tail flag when create inode

 fs/f2fs/data.c   | 61 ++++++++++++++++++++++++++++++++++++++++++++-
 fs/f2fs/f2fs.h   | 44 ++++++++++++++++++++++++++++++++-
 fs/f2fs/file.c   | 10 ++++++++
 fs/f2fs/inline.c | 64 ++++++++++++++++++++++++++++++++----------------
 fs/f2fs/inode.c  |  6 +++++
 fs/f2fs/namei.c  |  3 +++
 fs/f2fs/node.c   |  6 ++++-
 fs/f2fs/super.c  | 15 ++++++++++++
 8 files changed, 185 insertions(+), 24 deletions(-)

-- 
2.35.3


             reply	other threads:[~2024-07-10  1:19 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-07-10  1:33 Wu Bo via Linux-f2fs-devel [this message]
2024-07-10  1:33 ` [RFC PATCH 0/5] Add inline tail support Wu Bo
2024-07-10  1:33 ` [f2fs-dev] [RFC PATCH 1/5] f2fs: add inline tail mount option Wu Bo via Linux-f2fs-devel
2024-07-10  1:33   ` Wu Bo
2024-07-10  1:33 ` [f2fs-dev] [RFC PATCH 2/5] f2fs: add inline tail disk layout definition Wu Bo via Linux-f2fs-devel
2024-07-10  1:33   ` Wu Bo
2024-07-10  1:33 ` [f2fs-dev] [RFC PATCH 3/5] f2fs: implement inline tail write & truncate Wu Bo via Linux-f2fs-devel
2024-07-10  1:33   ` Wu Bo
2024-07-10  1:33 ` [f2fs-dev] [RFC PATCH 4/5] f2fs: implement inline tail read & fiemap Wu Bo via Linux-f2fs-devel
2024-07-10  1:33   ` Wu Bo
2024-07-10  1:33 ` [f2fs-dev] [RFC PATCH 5/5] f2fs: set inline tail flag when create inode Wu Bo via Linux-f2fs-devel
2024-07-10  1:33   ` Wu Bo
2024-07-12  7:12 ` [f2fs-dev] [RFC PATCH 0/5] Add inline tail support Chao Yu
2024-07-12  7:12   ` Chao Yu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=cover.1720515215.git.bo.wu@vivo.com \
    --to=linux-f2fs-devel@lists.sourceforge.net \
    --cc=bo.wu@vivo.com \
    --cc=chao@kernel.org \
    --cc=jaegeuk@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=wubo.oduw@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.