linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: Jaegeuk Kim <jaegeuk.kim@gmail.com>
Cc: Dave Chinner <david@fromorbit.com>,
	Jaegeuk Kim <jaegeuk.kim@samsung.com>,
	"'Vyacheslav Dubeyko'" <slava@dubeyko.com>,
	viro@zeniv.linux.org.uk, "'Theodore Ts'o'" <tytso@mit.edu>,
	gregkh@linuxfoundation.org, linux-kernel@vger.kernel.org,
	chur.lee@samsung.com, cm224.lee@samsung.com,
	jooyoung.hwang@samsung.com
Subject: Re: [PATCH 11/16] f2fs: add inode operations for special inodes
Date: Wed, 17 Oct 2012 12:50:11 +0000	[thread overview]
Message-ID: <201210171250.12130.arnd@arndb.de> (raw)
In-Reply-To: <1350426621.1958.119.camel@kjgkr>

On Tuesday 16 October 2012, Jaegeuk Kim wrote:
> > IIRC, fs2fs uses 4k inodes, so IMO per-inode xattr tress with
> > internal storage before spilling to an external block is probably
> > the best approach to take...
> 
> Yes, indeed this is the best approach to f2fs's xattr.
> Apart from giving fs hints, it is worth enough to optimize later.

I've thought a bit more about how this could be represented efficiently
in 4KB nodes. This would require a significant change of the way you
represent inodes, but can improve a number of things at the same time.

The idea is to replace the fixed area in the inode that contains block
pointers with an extensible TLV (type/length/value) list that can contain
multiple variable-length fields, like this. All TLVs together with the
fixed-length inode data can fill a 4KB block.

The obvious types would be:

* Direct file contents if the file is less than a block
* List of block pointers, as before, minimum 1, maximum until the end
  of the block
* List of indirect pointers, now also a variable length, similar to the
  list of block pointers
* List of double-indirect block pointers
* direct xattr: zero-terminated attribute name followed by contents
* indirect xattr: zero-terminated attribute name followed by up to
  16 block pointers to store a maximum of 64KB sized xattrs

This could be extended later to cover additional types, e.g. a list
of erase block pointers, triple-indirect blocks or extents.

As a variation of this, it would also be nice to turn around the order
in which the pointers are walked, to optimize for space and for growing
files, rather than for reading the beginning of a file. With this, you
can represent a 9 KB file using a list of two block pointers, and 1KB
of direct data, all in the inode. When the user adds another byte, you
only need to rewrite the inode. Similarly, a 5 MB file would have a
single indirect node (covering block pointers for 4 MB), plus 256
separate block pointers (covering the last megabyte), and a 5 GB file
can be represented using 1 double-indirect node and 256 indirect nodes,
and each of them can still be followed by direct "tail" data and
extended attributes.

	Arnd

  parent reply	other threads:[~2012-10-17 12:50 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-05 12:03 [PATCH 11/16] f2fs: add inode operations for special inodes 김재극
2012-10-06 18:59 ` Al Viro
2012-10-13 20:52 ` Arnd Bergmann
2012-10-13 21:57   ` Vyacheslav Dubeyko
2012-10-13 22:21   ` Vyacheslav Dubeyko
2012-10-14  7:09     ` Jaegeuk Kim
2012-10-14 12:06       ` Vyacheslav Dubeyko
2012-10-14 15:19         ` Arnd Bergmann
     [not found]           ` <CAN863PuYDSSFmaKtsVvdX4aFpS8hAMvFmhJpsky0x=ySn0QsqQ@mail.gmail.com>
2012-10-15 14:05             ` Arnd Bergmann
2012-10-16  2:29               ` Jaegeuk Kim
2012-10-16 16:14                 ` Arnd Bergmann
2012-10-16 21:43                   ` Jaegeuk Kim
2012-10-17  3:44                     ` Jaegeuk Kim
2012-10-17 12:22                       ` Arnd Bergmann
2012-10-17  8:35                     ` Arnd Bergmann
2012-10-15 22:34           ` Dave Chinner
2012-10-16  2:00             ` Jaegeuk Kim
2012-10-16 11:38               ` Arnd Bergmann
2012-10-16 20:38                 ` Jaegeuk Kim
2012-10-17 12:25                   ` Arnd Bergmann
2012-10-18  5:37                     ` Jaegeuk Kim
2012-10-16 20:44                 ` Dave Chinner
2012-10-16 22:30                   ` Jaegeuk Kim
2012-10-16 22:54                     ` Dave Chinner
2012-10-17  3:25                       ` Jaegeuk Kim
2012-10-17 12:50                     ` Arnd Bergmann [this message]
2012-10-24  2:49                       ` Dave Chinner
2012-10-24 12:02                         ` Arnd Bergmann
2012-10-14  6:51   ` Jaegeuk Kim

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=201210171250.12130.arnd@arndb.de \
    --to=arnd@arndb.de \
    --cc=chur.lee@samsung.com \
    --cc=cm224.lee@samsung.com \
    --cc=david@fromorbit.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=jaegeuk.kim@gmail.com \
    --cc=jaegeuk.kim@samsung.com \
    --cc=jooyoung.hwang@samsung.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=slava@dubeyko.com \
    --cc=tytso@mit.edu \
    --cc=viro@zeniv.linux.org.uk \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).